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
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
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)
1.84user 0.07system 0:01.91elapsed 99%CPU (0avgtext+0avgdata
0maxresident)k 0inputs+0outputs (227major+158minor)pagefaults 0swaps
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
> > 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.
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.
Enjoy the day,
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