Conrad's ALFS comments

Bill Maltby LFS Related lfsbill at wlmcs.com
Thu Aug 29 04:32:36 PDT 2002


On Thu, 29 Aug 2002, Heinz Kirchmann wrote:

> 
> > > I knew I shouldn't have answered.[...]

> > > If performance is an issue, you shouldn't use bash scripts in conjunction
> > > with heavy variable use anyway.
> > 
> > That's an arbitrary statement. When you need a Q&D (quick and dirty) pro-
> > cess, the economics (time, money, resources, expertise, beer) available
> > may dictate that an interpretive language be used. Performance may have
> > lower priority.
> If performance has lower priority, the little overhead created by
> longer variable names is neglectible. You have to take into account,
> that in general you are not having 1000 variables and the long
> version names will in general not be 10 times as long as the short
> versions.

Agreed. The little script was just an extreme example to demonstrate that
there was an impact. Since I am aware, and felt some may not be aware, I
thought it might be of interest.

> Furthermore, if you want to use many variables in a script (which in
> general means that you will do some 'programming stuff with loops and
> ifs' not just call some programs piping to each other), then bash
> definitely is a bad choice and perhaps you would do better
> to use perl or python or whatsoever.

Absolutely... if you know alternate languages. But if noobs are attempting
to program a task and shell script is all they know (for now - I hope they
continue learning) and they *must* get it done ASAP...

> Just to see the difference I translated your nice script into something
> similar in perl (I added it to the end of the mail just to proof I'm not
> cheating).

I would never suspect that without reason. But I'm glad you coded it
because it let me run it on the same box on which I ran the original bash
script. Got reductions almost as dramatic as yours below.

> Below you can see the results on my 33 Bogomips 486.
> First the results of your script:
> 
> # bash BMTest 
> 
> real    0m54.651s
> user    0m32.520s
> sys     0m22.130s
> -----------------------------------------
> 
> real    1m4.244s
> user    0m42.030s
> sys     0m22.220s
> 
> Then the results of the perl version:
> 
> # perl HKTest doIt
> Short version:
> 
> real    0m2.385s
> user    0m2.330s
> sys     0m0.060s
> Long version:
> 
> real    0m2.789s
> user    0m2.670s
> sys     0m0.120s

Similar on my RH 6.0 (appx 66.xx bogomips)

Short version:
1.84user 0.07system 0:01.91elapsed 99%CPU (0avgtext+0avgdata
    0maxresident)k 0inputs+0outputs (227major+158minor)pagefaults 0swaps
Long version:
2.07user 0.08system 0:02.14elapsed 100%CPU (0avgtext+0avgdata
    0maxresident)k 0inputs+0outputs (239major+193minor)pagefaults 0swaps

That box (my gateway only) has a very old everything and very slow HD. I
suspect that's why my 66.xx bogomips box does not seem to run twice as
fast as your appx. 33. And maybe the kernel/perl/lib versions.

> > ...
> > My point was only that the increased maintainability of longer names in-
> > volves a trade-off in performance. So, if you need to do an interpretive
> > implementation and it is on slow or heavily loaded equipment, you can help
> > performance by using short names.
> In my opinion there are better ways to help performance (see example above). In
> general you will win more, if you are using better algorithms or a programming
> language that fits better to your needs. Using cryptic abbreviations is the wrong
> way to go, that's what I say.

If other languages are known, agreed. But for those who do not know perl
or gawk or python or... If maintenance is not a big issue in a given case
and the implementer knows only one language, he may *reasonably* choose
shorter names. And I acknowledge the truth of your assertion that real-
world longer names in real world tasks will not have so dramatic an impact
as the extreme example I posed originally.

> > ... Maintainability can be helped by in-
> > creased commentary since it has much less effect (no memory management
> > needed for comments) and comments can be removed for the production ver-
> > sion.
> Comments are nice and important, but in general you won't add a commentary to each
> usage of a variable or call of a function. Long names improve readability much more.

Agree absolutely. And if clear understanding is clearly more important
than performance, I don't even think of using shorter names. It is only
when trying to get a balance of both maintainability and performance that
I even consider very short names. My failing is that once I start going
for the performance (in a given languange) I tend to go to extremes. :-(
3 months later, when I look at the code again... well you know where that
goes! :P

> > These same considerations could apply for any non-compiled/assembled im-
> > plementation.
> Yes, but as you said: if performance is the primary issue, you should better use
> a compiler. If not, the very little overhead is neglectible in almost all cases.

Yes. And that may provide the impetus for one to learn a new language.
Always a good thing! :-)

> Just my 2 Cents. Have a nice day.
> 
> Heinz
> 

I resisted the urge to see what gawk would do. I think it would be quite
similar to the perl results, since it also does a "pre-compilation".

And that gives a nice opportunity to end the thread, if you so desire.


><snip code> 

Enjoy the day,


Bill Maltby
billm at wlmcs.com


-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message



More information about the alfs-discuss mailing list