2

Is there any difference between the following (e.g. performance-wise):

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

versus doing it via a 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

The reason for asking is that I often run multiple (10-100 or more) simulation jobs on a workstation. Each job will run in a different working directory (and have a different input file, with a different set of parameters)--so scripting the runs will make it easier to run many tests over a large set of parameters. Some of the simulation runs could be over several days.

Would the difference in performance be negligible (i.e. < 5-10%)? Could the script (vs the command line) see a different environment and therefore cause something to go wrong?

  • N⁠⁠o⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠. – Michael Homer Mar 27 '15 at 6:20
  • Use time command and see it yourself. – Milind Dumbare Mar 27 '15 at 6:22
  • Your question is a little schizophrenic: First it asks "Does it make a difference?" but then it asks "Would the difference be negligible?". I answer "Yes" to the second version: I expect that the difference (if any) would be very small. – G-Man Mar 27 '15 at 6:24
  • The script will cost you at least one more shell fork than the command line + whatever time it takes to read it from the disk. That said, there could be significant speed increase in running a script versus a bash command despite the disadvantages mentioned if you make the shebang less specific. Performance-wise bash is kind of bottom of the barrel as shells go - if all of the shells got together and had a foot-race, bash's doctor would probably excuse it from particpating. @MichaelHomer - neat trick. – mikeserv Mar 27 '15 at 6:40
  • 1
    It might take 0.01s longer to start a script. However, it's likely to take you 2 seconds or more to re-enter the commands each time. Plus brain power to ensure you're running them in the right order. Surely hubris wins? – roaima Mar 27 '15 at 23:21
1

Executing mpirun from the command line or from a script doesn't change the performance of the mpirun command at all. The only performance difference is the startup time: running a script requires a few milliseconds at startup (more if the shell executable isn't in the disk cache), whereas typing on the command line requires however many seconds it takes you to type all that.

You can save a small amount of memory by telling the shell to replace itself by the last command it's running, instead of waiting for the last command to finish and terminate immediately. Replace mpirun … by exec mpirun ….

You can save a tiny amount of startup time by using dash instead of bash. For a long-running job like mpirun is likely to be, the difference is utterly negligible; the performance benefit is only visible in tasks that launch a lot of little shell scripts, such as booting Linux.

Putting the commands in a script has a major advantage: you can set up a sequence of commands, and if you want to make some tweaks to these commands, you just need to edit the file.

1

The performance difference will be negligible. The code itself will not run slower or faster in either case and starting it makes very little difference as the code for the bash binary is most likely already in memory.

1

Do you really consider starting those many commands manually? - This would certainly be very imperformant. (Maybe you want to explain that better in your question.)

Calling a script from a shell costs exactly one additional shell process; that's no issue at all, specifically if you have that many commands in your script. But having your commands together makes the handling and extensions easier.

Depending on the commands you have, and the way you call them, you may influence also your calling shell environment if you call the commands separately; for example in case of sourcing any called shell script based commands. Having all commands together in a script keeps changes local.

In short: there are quite some reasons to put all your commands in a script.

0

There will be a difference between but negligible as said by others. Here is how to check

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

But the performance really lies on automating and manually entering the commands one by one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.