Seq desempenho atingido ao especificar uma string de formato

Question

A execução do seq (GNU coreutils 8.21) sem especificar uma cadeia de formato é executada de forma extremamente rápida em comparação com qualquer formato possível que tentei:

$ time seq 1e8 > /dev/null
seq 1e8 > /dev/null
0.68s user 0.02s system 99% cpu 0.703 total

$ time seq -f '%1.f' 1e8 > /dev/null                                                                                                                                                                                                          
seq -f '%1.f' 1e8 > /dev/null
53.82s user 0.03s system 99% cpu 53.875 total

O que está acontecendo aqui? É possível reproduzir o desempenho ao fornecer explicitamente uma string de formato?

    

Answer 1

Essa é uma observação e tanto, mas na verdade faz sentido. Aqui está o código fonte: link

Primeiramente, observe a função seq_fast e o comentário antes de ser chamado:

608  /* If the following hold:
609     - no format string, [FIXME: relax this, eventually]
610     - integer start (or no start)
611     - integer end
612     - increment == 1 or not specified [FIXME: relax this, eventually]
613     then use the much more efficient integer-only code.  */

Nós vemos que eles têm um algoritmo melhor quando essas condições são atendidas. De fato, se adicionarmos um incremento, teremos o mesmo comportamento mais lento porque print_numbers é usado em vez de seq_fast :

time seq  1e9 > /dev/null 
seq 1e9 > /dev/null  4.68s user 0.09s system 99% cpu 4.770 total


time seq  1 7 1e9 > /dev/null
seq 1 7 1e9 > /dev/null  56.78s user 0.02s system 99% cpu 56.801 total

Por que a formatação demora ainda mais (1 minuto com 1e8 em vez de 1e9), observe que 53/10 ^ 8 segundos = 530 nanossegundos. Portanto, em média, o código de formatação (que deve ser executado em cada número antes da impressão) adiciona cerca de 530 nanossegundos por número impresso. Considerando toda a lógica complexa e complexa envolvida na formatação, isso também faz sentido.