DataInputStream не буферизуется, поэтому каждая операция чтения для объекта DataInputStream приведет к одному или большему числу чтений в основном потоке сокета, что может привести к нескольким системным вызовам эквивалент).
Системный вызов обычно на 2–3 порядка дороже, чем обычный вызов метода. Буферизованные потоки работают за счет уменьшения количества системных вызовов (в идеале до 1) за счет добавления дополнительного уровня регулярных вызовов методов. Обычно использование буферизованного потока заменяет N системных вызовов на 1 системный вызов и N дополнительных вызовов методов. Если N больше 1, вы выигрываете.
Из этого следует, что единственными случаями, когда BufferedInputStream между потоком сокета и DataInputStream является , а не выигрыш, являются:
- когда приложение выполняет только один
read...() вызов, и это может быть удовлетворено одним системным вызовом,
- , когда приложение выполняет только большие
read(byte[] ...) вызовы, или
- когда приложение ничего не читает.
Похоже, они не применимы в вашем случае.
Кроме того, даже если они применяются, накладные расходы на использование BufferedInputStream, когда вам это не нужно, относительно невелики. Затраты на использование BufferedInputStream, когда вам это нужно, могут быть огромными.
И последнее замечание: фактический объем прочитанных данных (то есть размер сообщений) составляет в значительной степени не имеет отношения к для буферизованной и небуферизованной головоломки. Что действительно важно, так это способ чтения данных; то есть последовательность read...() вызовов, которые будет выполнять ваше приложение.