bash vs sh vs mksh benchmark

intro

All 3 are sh compatible

I did a little benchmark for university. Originally I wasn't going to publish this, but then I decided what the heck, with the growing number of bash users

I did 3 test, one with bash one with mksh and one with sh. Before each test I rebooted my pc, to flush system cache
I was using my playd script to create playlist of 10K music files and god knows how many directories

bash
thumb_show.php


mksh
thumb_show.php


sh
thumb_show.php


Conclusion
as you can see mksh and sh beats the shit out of bash
I didn't thought mksh would perform so close to sh
 
re: shells/ksh93:port needs to be updated, it's looking for INIT.2010-03-01.tgz (at least to start with) and the version on the server is INIT.2010-03-09.tgz . . . I suppose they've bumped the numbers on all the other source files as well.
 
j_m said:
I am new to any shells, it seems that mksh attracts me.
A word of wisdom for you: pick a shell based on things which matter instead of things which might look cool or neat yet basically have little meaning.

Being familiar with the way a shell works (for example; you can quickly automate certain tasks) is far more valuable (or better: usable) than using one which might start a few microseconds faster than its competitors.
 
ShelLuser said:
A word of wisdom for you: pick a shell based on things which matter instead of things which might look cool or neat yet basically have little meaning.

Being familiar with the way a shell works (for example; you can quickly automate certain tasks) is far more valuable (or better: usable) than using one which might start a few microseconds faster than its competitors.

mksh is perfect for that.
  • It's fast
  • It's 100% sh compatible
  • It's very su-able
 
ksh93 is weird for most users because is uses a command edit system like vim, but it is one of the standard shells. Some old Unices carried it as an alternative to sh.
 
I think it is cool the script (which I can't access) performs at different speeds in different shells. Though I don't believe I've ever heard of someone picking one shell over another based on performance. Features and ease of understanding the syntax, sure, but has anyone here picked a shell based on raw performance?
 
NewGuy said:
I think it is cool the script (which I can't access) performs at different speeds in different shells. Though I don't believe I've ever heard of someone picking one shell over another based on performance. Features and ease of understanding the syntax, sure, but has anyone here picked a shell based on raw performance?

I didn't mention anything about ease of use of syntax. Syntax is 100% backwards compatible with Bourne shell (when you don't use extensions). As we all know the Bourne shell is the standard shell in Unix.
 
graudeejs said:
Syntax is 100% backwards compatible with Bourne shell (when you don't use extensions).
Not going into an argument here because I already shared my opinion on the matter, and also because I haven't tried mksh myself so I obviously can't comment on the program itself.

However, last time I heard an argument like yours was when someone claimed the same about ksh in comparison with sh, only this time the Bourne shell as it was used on Solaris. His exact words were: "ksh is a complete superset of sh, so it is not possible that sh scripts break using ksh." after which I showed him this script:

Code:
#!/bin/sh
ls -l /usr/bin ^ cut -d ' ' -f 1
Now, this doesn't work on FreeBSD (I tried out of curiosity) and the only reason I'm posting this anyway is because we're in the off-topic forum. Be careful with statements like yours unless you're absolutely sure, and quite frankly I don't think you can ever be. Many shells which have a rather large history behind them can sometimes support legacy functions which maybe hardly used, but which can still break compatibility, thus existing scripts.

I'm not claiming that this is the case here, as said before I haven't even tried mksh myself, just wanted to share this specific example because I think you make a dangerous claim which could come to haunt you.

Even Korn is mentioned to be "almost perfectly compatible" in channels which matter just because of examples like this, even though it will have no problems when used with the (major) majority of scripts which were specifically written for the Bourne shell.

Just my 2 cents here.
 
A bigger problem occurs when developers become dependent upon a certain shell/language/CPU/et cetera.
 
sossego said:
A bigger problem occurs when developers become dependent upon a certain shell/language/CPU/et cetera.

It is not a problem, it is a lie. Only need to know one shell/one language/one CPU architecture.
 
j_m said:
It is not a problem, it is a lie. Only need to know one shell/one language/one cpu arch

...said the dinosaur. Or was it the saber tooth?
 
Crivens said:
...said the dinosaur. Or was it the saber tooth?
+1 and quite right!

There are times when subsets of the same architecture will have different flags that must be invoked.
 
vermaden said:
Why use mksh if there is /bin/sh in the base with the same speed and compatibility?
Because you can.

Not looking for arguments here but I can turn your comment easily around: why use a rather static shell like /bin/sh while there's a dynamic shell such as mksh around with several enhancements? I mention "dynamic" because if you look at the main website and especially the changelog you'll notice that the last change (at the time of writing) was around 26-04-2013, I call that active development.

As said; not looking for arguments here because although it may sound weird I actually agree with you. My shell of preference on FreeBSD when it comes to scripting is also /bin/sh. But please be careful here; that doesn't mean that other shells cannot out-perform or otherwise "outdo" our shell of preference. It all depends on the job at hand.

Personally I prefer both Bourne (/bin/sh) and Korn (/usr/local/bin/ksh), but that doesn't mean they're better than everything else out there.

Always keep an open mind, never underestimate the value of choice.
 
ShelLuser said:
Because you can.

I thought that there was something more than that in mksh ;)

ShelLuser said:
I mention "dynamic" because if you look at the main website and especially the changelog you'll notice that the last change (at the time of writing) was around 26-04-2013, I call that active development.

Go and check http://freshbsd.org to see that /bin/sh in FreeBSD also receives updates regularly:
http://freshbsd.org/search?project=freebsd&q=head/bin/sh
 
vermaden said:
Why use mksh if there is /bin/sh in the base with the same speed and compatibility?

mksh
is more usable for human interaction. Command and file completion is written very well. In contrast every time I have to use bash, I curse almost every time I press tab key.
 
graudeejs said:

mksh
is more usable for human interaction. Command and file completion is written very well. In contrast every time I have to use bash, I curse almost every time I press tab key.

Usually I invent new swearwords when I accidently press ctrl-D instead of TAB on these shells.
 
Back
Top