Производительность Java byte [] и char [] для потока файлов

Question

Я пишу программу, которая читает файл (использует пользовательский буфер, 8 КБ), а затем находит ключевое слово в этом буфере. Поскольку Java предоставляет два типа потоков: символьные и байтовые, я реализовал это с использованием byte[] и char[] для буферизации.

Мне просто интересно, что было бы быстрее и лучше для производительности, поскольку char равно 2 byte, а при использовании Reader для считывания char[] Reader выполнит преобразование обратно из byte до char, что, я думаю, может сделать это медленнее, чем использование только byte[].

Answer 1

Использование байтового массива будет быстрее:

• У вас нет шага декодирования байтов в символы, который является, по крайней мере, циклом копирования, и, возможно, больше, в зависимости от Charsetиспользуется для декодирования.

• Массив байтов займет меньше места и, следовательно, сохранит циклы ЦП при GC / инициализации.

Однако:

• Если вы не ищете большие файлы, разница вряд ли будет существенной.

• Подход с использованием байтового массива может FAIL, если входной файл не закодирован в 8-битном наборе символов.И даже если это работает (как и для UTF-8 и UTF-16), существуют потенциальные проблемы с совпадающими символами, которые охватывают границы буфера.

(Причина побитовой обработкиработает для UTF-8 и UTF-16 в том, что кодирование позволяет легко различать первую единицу (байтовую или короткую) и последующие единицы закодированного символа.)

Answer 2

Если вы читаете двоичный файл, используйте байтовый массив.

Если это текстовый файл, и вы собираетесь использовать содержимое, например строки, то вам следует использовать массив символов.

Answer 3

Этот вопрос о переполнении стека file-streaming-in-java говорит о эффективной потоковой передаче файлов в java.

Мне особенно нравится эта справочная статья

В больших файлах вы быстро получаете преимущества скорости, используя только байты, поэтому, если вы можете декодировать шаблон с помощью байтов, вы можете окончательно получить несколько драгоценных циклов.

Если ваши файлы маленькие или у вас их не так много, возможно, это не стоит того.