Conrad's ALFS comments

Heinz Kirchmann kirchman at dfki.uni-kl.de
Thu Aug 29 00:54:31 PDT 2002


> > I knew I shouldn't have answered. Now I'm getting involved into one of 
> > those discussions...:-)
> Ah, they make life worth living! :)
If you say so, I will keep it alive :-)

> I like the one I saw on here that Klingon programmers do *not* annotate
> their code!
Yeah. Strange enough their spaceships do not crash every 100 meters.
Probably they have good beta testers.

> > 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.

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.
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).

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

> ...
> 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.

> ... 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.

> 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.

Just my 2 Cents. Have a nice day.

Heinz

=====================================================================
sub shortVariables {
  $C=0;
  while ( $C++ < 1000 ) {
    print "\$A${C}a=a${C};\n";
  }
print <<'EOF'
  $C=0;
  while ( $C++ < 1000 ) {
    $b=${ eval "A${C}a" };
    #print "$b\n";
  }
EOF
}

sub longVariables {
  $C=0;
  while ( $C++ < 1000 ) {
    print "\$ABDEFGHIJKLMNOPQRSTUVWXYZ${C}abcdefghijklmnopqrstuvwkyz=a${C};\n";
  }
print <<'EOF'
  $C=0;
  while ( $C++ < 1000 ) {
    $b=${ eval "ABDEFGHIJKLMNOPQRSTUVWXYZ${C}abcdefghijklmnopqrstuvwkyz" };
    #print "$b\n";
  }
EOF
}

if ( $ARGV[0] eq "s" ) {
  &shortVariables();
}
elsif ( $ARGV[0] eq "l" ) {
  &longVariables();
}

if ( $ARGV[0] eq "doIt" ) {
  `perl $0 s > /tmp/short$$`;
  print "Short version:\n";;
  print `time perl /tmp/short$$ 1>&2`;
  `perl $0 l > /tmp/long$$`;
  print "Long version:\n";
  print `time perl /tmp/long$$ 1>&2`;
}
=====================================================================


-- 
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