Позвольте мне снабдить это сообщение предисловием с единственной осторожностью. Я - общий новичок когда дело доходит до Java. Я программировал PHP на и прочь некоторое время, но я был готов подать настольную заявку, таким образом, я решил пойти с Java по различным причинам.
Приложение я продолжаю работать, находится в начальных стадиях (меньше чем 5 классов), и я должен считать байты из локального файла. Как правило, файлы в настоящее время - меньше чем 512 КБ (но может стать больше в будущем). В настоящее время я использую a FileInputStream
считать файл в три массива байтов, который отлично удовлетворяет мои требования. Однако я видел a BufferedInputStream
упомянутый, и задавался вопросом, является ли способ, которым я в настоящее время делаю это, лучшим, или если я должен использовать a BufferedInputStream
также.
Я провел некоторое исследование и считал несколько вопросов здесь на Переполнении стека, но я все еще испытываю затруднения при понимании лучшей ситуации для того, когда использовать и не использовать BufferedInputStream
. В моей ситуации первый массив я читал, байты только в несколько байтов (меньше чем 20). Если данные, которые я получаю, хороши в этих байтах, то я считал остальную часть файла в еще два массива байтов переменного размера.
Я также услышал, что многие люди упоминают, что представил для наблюдения, который более эффективен в каждом конкретном случае, однако, у меня нет профильного опыта, и я не действительно уверен, где запустить. Я любил бы некоторые предложения на этом также.
Я сожалею о таком длинном сообщении, но я действительно хочу изучить и понять лучший способ сделать эти вещи. У меня всегда есть дурная привычка к второму предположению моих решений, таким образом, я любил бы некоторую обратную связь.Спасибо!
Если вы постоянно выполняете небольшие чтения, тогда BufferedInputStream
даст вам значительно лучшую производительность. Каждый запрос чтения в небуферизованном потоке обычно приводит к системному вызову операционной системы для чтения запрошенного количества байтов. Накладные расходы на выполнение системного вызова могут составлять тысячи машинных инструкций на один системный вызов. Буферизованный поток уменьшает это, выполняя одно большое чтение (скажем) до 8 Кбайт во внутренний буфер, а затем передавая байты из этого буфера. Это может резко сократить количество системных вызовов.
Однако, если вы постоянно выполняете большие операции чтения (например, 8 КБ или более), то BufferedInputStream
замедляет работу. Обычно вы не уменьшаете количество системных вызовов, а буферизация вводит дополнительный этап копирования данных.
В вашем случае (когда вы сначала читаете 20-байтовый фрагмент, а затем много больших) я бы сказал, что использование BufferedInputStream
с большей вероятностью снизит производительность, чем повысит ее.Но в конечном итоге это зависит от реальных шаблонов чтения.
BufferedInputStream читает больше файла, который вам нужен заранее. Насколько я понимаю, он выполняет больше работы заранее, например, 1 большое непрерывное чтение с диска, а не выполнение многих в жестком цикле.
Что касается профилирования - мне нравится профилировщик, встроенный в netbeans. Начать работу действительно легко. : -)
Если вы используете относительно большие массивы для чтения данных по частям, то BufferedInputStream
просто создаст бесполезную копию. (Помните, что read
не обязательно читает весь массив - вам может понадобиться DataInputStream.readFully
). BufferedInputStream
побеждает при выполнении большого количества небольших чтений.
Я не могу говорить о профилировании, но, исходя из моего опыта разработки приложений Java, я обнаружил, что при использовании любого из классов буферов - BufferedInputStream, StringBuffer - мои приложения работают исключительно быстрее. Из-за чего я использую их даже для самых маленьких файлов или строковых операций.