paulo1205
(usa Ubuntu)
Enviado em 14/05/2023 - 02:35h
Você também pode invocar o meu script a partir de redirecionamento de linha de comando.
caesar <<<"Viva o Linux"
Sobre a medição dos tempos, considere o seguinte:
• Uma máquina ocupada (por exemplo: com ambiente gráfico aberto, incluindo um navegador web exibindo coisas que gastam muita CPU, tal como a página do Viva o Linux, infelizmente) pode acabar perdendo tempo com outras coisas além do que você está medindo e afetar sua medição.
• O mesmo vale para outras coisas (por exemplo:
crond executando tarefas,
dumps do
cache de disco, realização de
back-ups, verificação da superfície dos discos ou estado de RAID, outros programas em
background etc.).
• Para minimizar o impacto de fatores externos, pode ser conveniente aumentar o número de rodadas. Por exemplo, em vez de apenas 100, considere algo como 10000, ou maior ainda que isso.
• Cuidado para não medir a própria medição. Quando você faz algo como “
time for (( ... )); do comando_externo < arquivo; done”, especialmente para um comando externo de curta duração, boa parte do esforço vai estar no trabalho do próprio
shell que, para cada iteração do laço de repetição criado pelo comando
for, tem de criar um redirecionamento a partir de um arquivo, criar processo novo (
fork()), executar o comando externo (
execve()) e depois liberar recursos quando o comando externo acabar de executar. Essa situação pode ser um pouco difícil de contornar quando você usa somente o
shell, porque ele não tem uma instrumentação muito boa para esse tipo de medição, e mesmo que você use dados obtidos a partir do diretório
/proc do Linux, tais informações não dão uma resolução muito boa.
Eu acabei me empolgando aqui com essa questão e fiz cinco versões do programa cifrador, a fim de comparar desempenho usando interpretadores com recursos diferentes: uma para
bash e que também funciona sem modificações no
ksh93 e no
zsh, uma para o velho
sh (ou quase), uma para Perl, uma para Python e uma em C. Fiz também quatro versões de um programa para medir o desempenho dos cifradores, sendo uma para
bash, uma para
ksh, uma para
zsh e uma em C.
Os resultados me surpreenderam um pouco. Eu sabia que os programas em C teriam um
overhead menor e, no caso do programa medidor, muito melhor resolução de medida, mas fiquei um consideravelmente decepcionado com o desempenho do Perl em relação aos
shells, já que ele implementa nativamente uma função equivalente ao comando
tr, que os
shells acabam todos tendo de invocar como programa externo, e muito decepcionado com o Python, que, apesar de não ter de invocar nenhum comando externo, perdeu feio até para o
sh velho de guerra, que tem de invocar comandos externos até para fazer operações aritméticas e testes lógicos. Também me surpreenderam a inconsistência interna e incompatibilidades gratuitas entre o
zsh e os outros
shells. Entre os
shells, o
ksh foi o vencedor inconteste, tanto em desempenho quanto com relação a recursos oferecidos (pelo menos para os testes em questão, não necessariamente para outros usos). É uma pena que ele não seja tão conhecido e divulgado quanto o
bash ou o
zsh.
Caso tenham interesse, avisem-me, que eu posso postar aqui os programas, os resultados, e algumas análises.
... Então Jesus afirmou de novo: “(...) eu vim para que tenham vida, e a tenham plenamente.” (João 10:7-10)
