13 Aug
2006
13 Aug
'06
6:37 p.m.
Don wrote:
Ethan Dicks wrote:
That's exactly the kind of stuff I have to deal with on a
regular basis. We have a large database manipulation application
full of classes with accessor methods that return instances of
string classes. Copy constructors executing all over the place.
Memory being uselessly copied from place to place accounts for
over 30 percent of the app's CPU usage. Programmer's response
to the suggestion that maybe some of the accessors return
(const char *) insead?
"That's just wrong." "My classes are bullet proof."
"Someone
could recast the pointer and sabotage my classes." "Modern
computers have plenty of CPU capacity."
This code does not go out of our shop... We all regularly
review each other's code but he spouts all of the "patterns"
nonsense.
On 8/14/06, Don <THX1138 at dakotacom.net>
wrote:
The "everything should be in assembler" (paraphrased) comment has
some merit -- you get to see what the machine is *really* doing
at your behest.
Of course, doing *everything* that way quickly becomes
counterproductive (and, doesn't eliminate the need for
"quality programmers")
I don't blame languages. I blame the folks
who either
don't fully understand the characteristics/consequences of
certain language features *or* the folks who don't
understand (nor appreciate) how to *test* things.
Agreed. I ran into a Perl debugging situation at one company where
the code to hit the database and aggregate thousands of e-mail
addresses was written by a web developer and then handed off to a
database developer when the first guy left. Essentially, the problem
was that on a particular day, the code, which had been working, got
swamped because it was (legitimately) being asked to handle 20 times
the normal amount of recipients. At the bottom of everything, there
was a loop with '$x .= $r[$n]' sort of a construct in it to build a
list of names, and there was so much string copying going on in the
loop that the Perl interpreter eventually barfed (after chewing on the
list for 8 hours). My solution was to replace the inner loop with a
'$x = $r[$a..$b]' construct - the modified program ran to completion
in 20 minutes. The "real" problem was that the first
guy didn't really understand the
impact of his original construction on the underlying system, and "it
worked" for a few thousand names. Didn't scale worth beans, though.
Exactly. Like:
for (x=0; x<XMAX; x++)
for (y=0; y<YMAX; y++)
foo[x][y] = ...;
vs.
for (y=0; y<YMAX; y++)
for (x=0; x<XMAX; x++)
foo[x][y] = ...;
They *look* the same but *aren't*.
And, in languages like C++, all of the machinery going
on "behind the scenes" (automatic type conversion,
constructor invocations, etc.) is so far out of the
typical "programmer's" mind/scope of knowledge that
it's a wonder *anything* works! :-(
I found one piece of code that was literally counting bytes
to determine the size of a file instead of stat(2)-ing it
(no, it wasn't a sparse file, special device, etc. ... just
a regular "box of bytes")