Faz diferença (por exemplo, performance-wise) se eu executar um comando de um script bash (vs a linha de comando)?

Question

Existe alguma diferença entre o seguinte (por exemplo, desempenho-wise):

$ make && cp bin/myexecutable inputfile.txt $workdir && cd $workdir
$ <series of sed commands to modify inputfile.txt>
$ mpirun -n 12 ./myexecutable [args]

versus fazer isso por meio de um script:

myscript.sh:

#!/bin/bash
make && cp bin/myexecutable inputfile.txt $workdir && cd $workdir
<series of sed commands to modify inputfile.txt>
mpirun -n 12 ./myexecutable [args]

+

$ ./myscript.sh

A razão para perguntar é que muitas vezes eu executo vários trabalhos de simulação (10-100 ou mais) em uma estação de trabalho. Cada trabalho será executado em um diretório de trabalho diferente (e terá um arquivo de entrada diferente, com um conjunto diferente de parâmetros) - portanto, a execução de scripts nas execuções facilitará a execução de muitos testes em um grande conjunto de parâmetros. Algumas execuções de simulação podem durar vários dias.

A diferença no desempenho seria insignificante (isto é, < 5-10%)? Poderia o script (vs a linha de comando) ver um ambiente diferente e, portanto, fazer algo dar errado?

    

Answer 1

Executar mpirun da linha de comando ou de um script não altera o desempenho do comando mpirun . A única diferença de desempenho é o tempo de inicialização: a execução de um script requer alguns milissegundos na inicialização (mais se o executável do shell não estiver no cache de disco), enquanto digitar na linha de comando requer quantos segundos você digitar. .

Você pode salvar uma pequena quantidade de memória dizendo ao shell para se substituir pelo último comando que está sendo executado, em vez de esperar que o último comando termine e termine imediatamente. Substitua mpirun … por exec mpirun … .

Você pode economizar uma pequena quantidade de tempo de inicialização usando traço em vez de bash. Para um trabalho de longa duração como o mpirun provavelmente será, a diferença é totalmente insignificante; o benefício de desempenho é visível apenas em tarefas que executam muitos pequenos scripts de shell, como a inicialização do Linux.

Colocar os comandos em um script tem uma grande vantagem: você pode configurar uma sequência de comandos e, se quiser fazer alguns ajustes para esses comandos, basta editar o arquivo.

    

Answer 2

A diferença de desempenho será insignificante. O código em si não rodará mais devagar ou mais rápido em ambos os casos e, se iniciar, fará pouca diferença, já que o código do binário bash provavelmente já está na memória.

    

Answer 3

Você realmente considera iniciar esses muitos comandos manualmente? - Isso certamente seria muito imperfeito. (Talvez você queira explicar isso melhor na sua pergunta.)

Chamar um script de um shell custa exatamente um processo de shell adicional; isso não é problema, especificamente se você tiver muitos comandos em seu script. Mas ter seus comandos juntos facilita o manuseio e as extensões.

Dependendo dos comandos que você tem e da maneira como você os chama, você pode influenciar também o ambiente de shell de chamada se chamar os comandos separadamente; por exemplo, no caso de terceirizar qualquer comando baseado em script de shell chamado. Ter todos os comandos juntos em um script mantém as alterações locais.

Resumindo: existem algumas razões para colocar todos os seus comandos em um script.

    

Answer 4

Haverá uma diferença entre mas insignificante como dito por outros. Aqui está como verificar

macair:scripts $ time ps
  PID TTY           TIME CMD
  437 ttys000    0:00.01 -bash
  442 ttys001    0:00.43 -bash

real    0m0.009s
user    0m0.002s
sys     0m0.007s

macair:scripts $ time ./ps.sh 
  PID TTY           TIME CMD
  437 ttys000    0:00.01 -bash
  442 ttys001    0:00.44 -bash
32559 ttys001    0:00.00 /bin/bash ./ps.sh

real    0m0.012s
user    0m0.004s
sys     0m0.008s
macair:scripts $ cat ps.sh 
#!/bin/bash

ps
macair:scripts $ echo $SHELL
/bin/bash

Mas o desempenho realmente está em automatizar e inserir manualmente os comandos, um por um.