4 ms·

Thanks for your reply. Yes, the ready availability of the code would be a plus. In my mind utilities like grep or sort are very sensitive in terms of performanc

• deckiedan 11y ago
  Oh yes, absolutely. That is the big tradeoff. One could hope that with many of these utils they're mostly IO bound, and so a scripting language wouldn't change that much. I know at one point I actually had a python based md5sum that was faster than the regular gnu one for big files - as it loaded the data off the disk in huge chunks. I believe ack-grep was written in perl? And that's pretty fast. Also - how fast does it Actually need to be? It's not high-frequency-trading or a 60fps game... A computer these days can probably load perl, run a script, and display the output faster than a computer from 20 years ago could run the original c util... And if everything is written in it, then a lot will be already in memory. If your shell is written in it too, then you could just call the utils from within there, rather than having to fork/exec it anyway. For most higher level scripting languages (such as perl, python, ruby, etc). Things like regexps and hash tables are written in c underneath anyway. With a lot of shell scripting, you call many many utils many times - which would slow everything down hugely if you needed the scripting language startup costs each time. However, if you use the same higher-level scripting language to write all your scripts in - rather than writing SH scripts that call your utilities, then you might even get faster than SH calling external utils (possibly). (If that makes sense...)