O tamanho ideal do buffer está relacionado a várias coisas: tamanho do bloco do sistema de arquivos, tamanho do cache da CPU e latência do cache.
A maioria dos sistemas de arquivos está configurada para usar tamanhos de bloco de 4096 ou 8192. Em teoria, se você configurar o tamanho do buffer para ler alguns bytes a mais do que o bloco de disco, as operações com o sistema de arquivos podem ser extremamente ineficientes (por exemplo, se você configurou seu buffer para ler 4100 bytes de cada vez, cada leitura exigiria 2 leituras de bloco pelo sistema de arquivos). Se os blocos já estiverem no cache, você acaba pagando o preço da RAM -> latência do cache L3 / L2. Se você não tiver sorte e os blocos ainda não estiverem no cache, pagará o preço da latência do disco-> RAM também.
É por isso que você vê a maioria dos buffers dimensionados com uma potência de 2 e geralmente maior que (ou igual ao) tamanho do bloco de disco. Isso significa que uma de suas leituras de fluxo pode resultar em várias leituras de bloco de disco - mas essas leituras sempre usarão um bloco completo - nenhuma leitura desperdiçada.
Agora, isso é bastante compensado em um cenário típico de streaming, porque o bloco que é lido do disco ainda estará na memória quando você clicar na próxima leitura (afinal, estamos fazendo leituras sequenciais aqui) - então você acaba pagando o preço da latência do cache RAM -> L3 / L2 na próxima leitura, mas não a latência do disco-> RAM. Em termos de ordem de magnitude, a latência do disco-> RAM é tão lenta que praticamente inverte qualquer outra latência com a qual você esteja lidando.
Portanto, suspeito que, se você executou um teste com diferentes tamanhos de cache (provavelmente não o fez), provavelmente encontrará um grande impacto no tamanho do cache até o tamanho do bloco do sistema de arquivos. Acima disso, suspeito que as coisas se estabilizariam rapidamente.
Há uma tonelada condições e exceções aqui - as complexidades do sistema são realmente surpreendentes (apenas controlar as transferências de cache L3 -> L2 é incrivelmente complexo e muda com todos os tipos de CPU).
Isso leva à resposta do 'mundo real': se seu aplicativo estiver em 99%, defina o tamanho do cache como 8192 e siga em frente (melhor ainda, escolha o encapsulamento sobre o desempenho e use BufferedInputStream para ocultar os detalhes). Se você estiver no 1% dos aplicativos que são altamente dependentes da taxa de transferência do disco, elabore sua implementação para que você possa trocar diferentes estratégias de interação do disco e forneça os botões e discagens para permitir que seus usuários testem e otimizem (ou apresentem algumas sistema de auto-otimização).