[ale] Bash vs Perl

Steve Litt slitt at troubleshooters.com
Wed Oct 26 02:05:35 EDT 2016


On Tue, 25 Oct 2016 11:01:40 -0400
leam hall <leamhall at gmail.com> wrote:

> On Tue, Oct 25, 2016 at 10:57 AM, Steve Litt
> <slitt at troubleshooters.com> wrote:
> 
> > On Mon, 24 Oct 2016 12:08:48 -0400
> > leam hall <leamhall at gmail.com> wrote:
> >  
> > > My unsolicited opinion, based off using Ruby, is that if the cost
> > > of a fork is critical use C or Go. Otherwise, "a difference that
> > > makes no difference is no difference".  
> >
> > Bash **REALLY** slows for fork. Run the test program inside a big
> > loop. If I remember correctly, it's an order of magnitude slower
> > than the same loop in Python, all because of spawning test.
> >
> > High repetition loops in Bash are much worse than in Python or Perl.
> >
> > SteveT
> >  
> 
> Hey Steve, that was sort of my point. If the fork is run once a day
> and takes 5 minutes instead of 2, is that really a problem? Granted
> there are much better technical solutions, but if you only have so
> much time to code, is the performace gain worth the effort?

Exactly! Bash is great for most stuff. The exception is iterating
through a directory with a thousand or so files, and for some reason
run the test executable on each. That could take 10 minutes for bash as
opposed to 30 seconds for Python and 8 seconds for C (these timings are
my best guesses).

By the way, Bash excels at performance when you use lots of pipes and
do them right.

grep -v "^\s*#" < giant.file | grep -v "^\s*$" | format_my_info.sh

It's a pretty good way of multiprocessing without multiprocessing
programming techniques, and it's a good way of making all loops happen
in C-written programs (grep), not Bash where iteration takes forever.

Thanks.

SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28




More information about the Ale mailing list