Duvido que meu entendimento da saída da execução do timecomando GNU esteja correto. Agora estou me perguntando o que a porcentagem da CPU realmente indica.
No macOS, instalei o timeutilitário GNU gtimeusando homebrew e executei um comando muito simples para verificar sua função:
/usr/local/bin/gtime -f '\ntime: system %S user %U elapsed %e CPU %P \nstat: %x' echo hi
hi
time: system 0.00 user 0.00 elapsed 0.00 CPU 100%
stat: 0
executando um comando mais simples usando o mesmo utilitário com menos sinalizadores:
/usr/local/bin/gtime echo hi
hi
0.00user 0.00system 0:00.00elapsed 75%CPU (0avgtext+0avgdata 676maxresident)k
0inputs+0outputs (1major+420minor)pagefaults 0swaps
As páginas do manual afirmam
%S tempo do sistema (kernel) em segundos
%P porcentagem da CPU que este trabalho obteve
%U tempo do usuário em segundos
Isso significa que o comando foi ineficiente, usando 100% da CPU, ou significa que ele é muito eficiente, ou nenhum dos dois.
Eu executei alguns outros scripts de shell muito mais complexos usando gtimee eles mostram uma variedade de CPU 5%– CPU 9%o que me levou a fazer esta pergunta.
No macOS, %CPU indica qual porcentagem de tempo o software em questão estava usando na CPU, durante o período de tempo coberto pela medição. É medido em relação a um único núcleo da CPU, então 100% significa 100% de um núcleo . Você pode ver porcentagens acima de 100%, já que todas as CPUs modernas têm múltiplos núcleos.
Números menores significam que menos tempo de CPU foi usado, o que é bom do ponto de vista do gerenciamento de recursos, mas essa medição por si só não é suficiente para dizer se seu software é eficiente ou não, porque você não tem nada com que compará-lo.
Por exemplo, se você tivesse um algoritmo de classificação que classificasse um conjunto de dados em 10 segundos usando 100% de um núcleo de CPU durante esse tempo, isso seria apenas um ponto de dados. Esse algoritmo era eficiente ou não? Quem sabe?! Mas se você obtiver um segundo ponto de dados alternando para um algoritmo diferente e ele classificar o mesmo conjunto de dados inicial em 5 segundos usando 100% de um núcleo de CPU durante esse tempo, agora você sabe que o primeiro algoritmo não foi tão eficiente quanto poderia ser.
Saber que um aplicativo single-threaded está usando 100% de um núcleo de CPU pode ser um sinal de que o trabalho que ele está realizando é limitado pela CPU. Ou seja, ele não está esperando que as coisas sejam lidas ou gravadas na RAM, no armazenamento, na rede ou em algum outro dispositivo de E/S; a única coisa que o impede de ter um desempenho mais rápido é a quantidade de trabalho que ele precisa fazer na CPU e o fato de que ele não está paralelizando seu trabalho em outros núcleos de CPU.
Se você tem um software single-threaded que nunca usa 100% da CPU, então o trabalho que ele está fazendo não está sendo limitado pelo poder de um núcleo de CPU. Ele possivelmente está sendo limitado por outros fatores, como RAM disponível ou espera por E/S. Ou talvez ele deva ser apenas um processo silencioso em segundo plano que monitora as coisas, não algo projetado para processar um monte de dados o mais rápido possível.