Pergunta sobre a eficiência de E / S sem buffer introduzida no APUE 3, 3.9

Question

Em Programação Avançada em Unix Environment 3th, 3.9, E / S Efficiency, eu li sobre isso:

The file was read using the program shown in Figure 3.5, with standard output redirected to /dev/null. The file system used for this test was the Linux ext4 file system with 4,096-byte blocks. (The st_blksize value, which we describe in Section 4.12, is 4,096.) This accounts for the minimum in the system time occurring at the few timing measurements starting around a BUFFSIZE of 4,096. Increasing the buffer size beyond this limit has little positive effect.

Minha pergunta é por que "Aumentar o tamanho do buffer além desse limite tem pouco efeito positivo"? Acho que aumentar o tamanho do buffer definitivamente reduzirá o tempo de CPU do usuário e o tempo de CPU do sistema, devido à redução do número de loops, de modo que o tempo do relógio também seja reduzido a determinados graus. E por quê?

    

Answer 1

A declaração "Aumentar o tamanho do buffer além desse limite tem pouco efeito positivo" não tem credibilidade.

O código como postado não dá qualquer indicação sobre quantos bytes são realmente lidos e depois escritos em cada iteração de loop - via dados lidos de um canal - redirecionados stdin . Dado que o valor de PIPE_BUF do Linux é normalmente 5120 bytes, o código provavelmente lê e grava um punhado de kilobytes com cada iteração de loop.

Uma vez que o tamanho do buffer cresce mais do que isso, o número de bytes realmente movidos com cada iteração de loop não muda, então o tamanho do buffer é completamente irrelevante.

Além disso, a metodologia do teste é completamente não documentada. Como os arquivos são transferidos para o processo? As páginas dos livros postadas em link não especifica - em tudo . Não há como duplicar o teste porque não podemos dizer qual foi o teste .

Além disso, a leitura atenta do código no link indica vários problemas - read() e write() são codificados como se retornassem int em vez dos ssize_t corretos, os manipuladores de sinal fazem chamadas para funções assíncronas de sinal inseguro .

Em outras palavras, o código slipshod e os testes slipshod.