Clean code vs. efficiency

  • Thread starter Christopher Benson-Manica
  • Start date
C

Christopher Benson-Manica

Yesterday I changed some code to use std::vectors and std::strings
instead of character arrays. My boss asked me today why I did it, and
I said that the code looks cleaner this way. He countered by saying
that he was regarded the dyanamic allocation that C++ STL classes
perform as being very inefficient. He also said that he wasn't
particularly interested in clean code (!). My question to the group:
In what situations, if any, would you use fast but hackish C-style
code in favor of the convenient STL classes? Would your answer change
if you were forced to use a questionable implementation (such as,
not-so-hypothetically, Borland 4)?
 
K

Karl Heinz Buchegger

Christopher said:
Yesterday I changed some code to use std::vectors and std::strings
instead of character arrays. My boss asked me today why I did it, and
I said that the code looks cleaner this way. He countered by saying
that he was regarded the dyanamic allocation that C++ STL classes
perform as being very inefficient.

Really?
Has he tried it?
Does he have some performance data?

In most cases there is next to no difference in execution speed.
 
?

=?ISO-8859-15?Q?Juli=E1n?= Albo

Christopher said:
Yesterday I changed some code to use std::vectors and std::strings
instead of character arrays. My boss asked me today why I did it, and
I said that the code looks cleaner this way. He countered by saying
that he was regarded the dyanamic allocation that C++ STL classes
perform as being very inefficient. He also said that he wasn't
particularly interested in clean code (!). My question to the group:
In what situations, if any, would you use fast but hackish C-style
code in favor of the convenient STL classes?

Exactly in this case: when the boss say that you must do it.
 
J

jeffc

Christopher Benson-Manica said:
Yesterday I changed some code to use std::vectors and std::strings
instead of character arrays. My boss asked me today why I did it, and
I said that the code looks cleaner this way. He countered by saying
that he was regarded the dyanamic allocation that C++ STL classes
perform as being very inefficient. He also said that he wasn't
particularly interested in clean code (!). My question to the group:
In what situations, if any, would you use fast but hackish C-style
code in favor of the convenient STL classes?

Frankly, it sounds like your manager doesn't *really* know what he's talking
about. There is far, far more money wasted on fixing and customizing and
maintaining hard-to-read code than there is lost on inefficient code. Now
it just could be that your compiler does a crappy job with these things and
it is slow. But on the other hand, it still might not matter! (Does it
really matter to the user if something takes .03 seconds or .01 seconds?)
 
S

Stephen Waits

Christopher said:
Yesterday I changed some code to use std::vectors and std::strings
instead of character arrays. My boss asked me today why I did it, and
I said that the code looks cleaner this way. He countered by saying
that he was regarded the dyanamic allocation that C++ STL classes
perform as being very inefficient. He also said that he wasn't
particularly interested in clean code (!). My question to the group:
In what situations, if any, would you use fast but hackish C-style
code in favor of the convenient STL classes? Would your answer change
if you were forced to use a questionable implementation (such as,
not-so-hypothetically, Borland 4)?

Well, you don't say if you're talking about some type of inner-loop, or
whatever, but still... in general...

Your boss is wrong.

Writing messy code is VERY expensive. You'll spend more time debugging
it. It will be less maintainable. It will lead to hacks upon hacks.
Vicious circle.

Clean code should ALWAYS be the first priority. Performance driven
(less clean, hacky) code should NEVER be implemented first. Only
optimize when you have to, and the minimum you have to. This is what a
profiler is for. Has your boss run a profiler and determined that your
new STL usage is his hot spot? Probably not.

Write clean code. When you're finished, if it's fast enough, then
you're done! [and you have easier-to-debug, more-maintainable,
nice-code to boot]. If it's NOT fast enough, profile it, and optimize
your hot spots.

Meanwhile, I'd try to tactfully explain this to your boss. If he
doesn't understand, then, well, don't say anything to him, but you
should probably start looking for another job because you're working for
a dumb ass.

--Steve

[NOTE: I am a game programmer. Have been (professionally) for 8 years.
We require the utmost of performance. While we don't use STL in our
game code, we use our own somewhat similar stuff. Anyway, it doesn't
matter that he decided to use STL as his example, he is JUST PLAIN WRONG..]
 
D

Default User

Karl said:
Really?
Has he tried it?
Does he have some performance data?


Since when does the boss have to prove things to subordinates?

Christopher is the one who wants to introduce changes to the code base,
it's up to him to program it both ways and perform benchmark testing on
it. A nice boss would let him try that on company time, a hardheaded one
would suggest that weekends are made for such experiments.



Brian Rodenborn
 
S

Siemel Naran

Christopher Benson-Manica said:
Yesterday I changed some code to use std::vectors and std::strings
instead of character arrays. My boss asked me today why I did it, and
I said that the code looks cleaner this way. He countered by saying
that he was regarded the dyanamic allocation that C++ STL classes
perform as being very inefficient. He also said that he wasn't
particularly interested in clean code (!). My question to the group:
In what situations, if any, would you use fast but hackish C-style
code in favor of the convenient STL classes? Would your answer change
if you were forced to use a questionable implementation (such as,
not-so-hypothetically, Borland 4)?

By char arrays, do you mean
char array[200];
array = new char[200]; delete[] array;
array = static_cast<char*>(malloc(200u)); free(array);
array = ::eek:perator new(200u); ::eek:perator delete(array);

As regards memory allocation, the first way may be slightly faster, but not
always. The 2nd, 3rd, and 4th ways are usually the same. The default STL
allocators use the 4th way.

Which way is faster depends very much on the details of your scenario, such
as the size of the array, number of objects created, etc. If you create
lots of small arrays, then the 1st way may be faster.

In general, the STL containers are extremely fast, and might be faster than
your home-grown containers due to specializations, fancy algorithms, etc.

The STL allocators let you use pool allocators, but you can also that by
overloading Class:eek:perator new. In the first case, the pool may be per
container; and in the second, the pool is shared across containers.

The STL containers also destruct their data by calling allocator.destroy on
each element, though in a good compiler this would be optimized away when
the element is a POD, as the statement has no effect.

The STL containers also default initialize their members, if you provide a
size parameter (but don't confuse this with reserve).

But std::string implementations may also provide an optimization for small
strings, namely to contain an element like char[32]. I don't know much
about this topic though, or whether any real implementations actually do
this.

As regards the topic of clean code versus hackish code, my theory is that
hackish code is easier to write and therefore produces immediate business
value (ie. profits). But it is harder to maintain and so over the long term
is more costly. How businesses fare with either method is an interesting
topic, and I have not done any formal research into the subject.

But also be aware that usage of STL does not automatically mean your code is
cleaner.
 
J

Juergen Heinzl

Yesterday I changed some code to use std::vectors and std::strings
instead of character arrays. My boss asked me today why I did it, and
I said that the code looks cleaner this way. He countered by saying
that he was regarded the dyanamic allocation that C++ STL classes
perform as being very inefficient. He also said that he wasn't
particularly interested in clean code (!). My question to the group:
In what situations, if any, would you use fast but hackish C-style
code in favor of the convenient STL classes? Would your answer change
if you were forced to use a questionable implementation (such as,
not-so-hypothetically, Borland 4)?
[-]
IMHO clean code tends to be faster than "hackish" C-style code plus
I'd like to add writing clean C code is as easy as writing unreadable
and arcane crap in C++.

Or to cite myself (since no-one ever else does) -- "If the compiler
loves my code I got it right".

Changes to an existing code base are an tricky issue, though and
just making some changes here and there may just be what you want
to avoid -- a quick and dirty hack.

Not to mention the whole thing needs to be re-tested and your
project manager needs to give his or her thumbs up and it may
result in an unpleasent surprise for others who rely on the original
design (if there's any, that is) and ...

Well, and last but not least although bosses ought to mature enough
to rely on their developers abilities it's never a good idea to
start an argument with your boss for *he* is the one who's in
a position to fire *you*.

Cheers,
Juergen
 
S

Stephen Waits

Siemel said:
In general, the STL containers are extremely fast, and might be faster than
your home-grown containers due to specializations, fancy algorithms, etc.

There was a mildly interesting talk at the Game Developers' Conference
this year given by a guy from the Xbox ATG.

ATG is a group that Xbox developers (1st & 3rd party) turn to for
optimization. They've seen LOTS of games and TONS of code in the past
few years.

This speaker mentioned that in *every single case*, the STL (shipping
with Xbox DK's, probably Roguewave?) outperformed the home brew lists,
arrays, maps, trees, etc.

He also mentioned lots of other mostly retarded things they'd found.
Most were unbelievable stupid, but that's OT.
But also be aware that usage of STL does not automatically mean your code is
cleaner.

Excellent point.. Though, it probably generally helps. I know most
one-off tools I've written in the past 5 or so years (with STL) look
much cleaner than those I wrote prior to that (without STL).

--Steve
 
C

Claudio Puviani

Stephen Waits said:
There was a mildly interesting talk at the Game Developers' Conference
this year given by a guy from the Xbox ATG.

ATG is a group that Xbox developers (1st & 3rd party) turn to for
optimization. They've seen LOTS of games and TONS of code in the past
few years.

This speaker mentioned that in *every single case*, the STL (shipping
with Xbox DK's, probably Roguewave?) outperformed the home brew lists,
arrays, maps, trees, etc.

That this happens in some -- maybe even most -- cases, doesn't make it a rule
(I'm not claiming that you're passing it off as one). When I was working with
John Lakos, he had written a family of replacement containers that consistently
outperformed Standard Library containers by a substantial margin, at the expense
of ease of use and, in some specific cases, generality. I'll be the first to
argue that in most cases, the Standard Library is more than adequate and should
be the first choice, but it's by no means the most runtime-efficient way to do
things for all situations.
He also mentioned lots of other mostly retarded things they'd found.
Most were unbelievable stupid, but that's OT.

And specific to their particular code base.

Definitely. I've seen some mighty ugly code that used Standard containers.

Claudio Puviani
 
E

E. Robert Tisdale

Christopher said:
Yesterday I changed some code to use std::vectors and std::strings
instead of character arrays. My boss asked me today why I did it,
and I said that the code looks cleaner this way.

You broke the zero'th rule of code maintenance:

If it ain't broke, don't fix it.

Your observation that the code "looks cleaner" is far too subjective
to justify recoding working code and risking introduction of new bugs.
He countered by saying that he was regarded the dynamic allocation
that C++ STL classes perform as being very inefficient.

He is almost certainly wrong.
He also said that he wasn't particularly interested in clean code (!).

He probably doesn't know what you mean by "clean code".
I don't either.
You need to show that value was added by "cleaning up this code".
My question to the group: In what situations, if any,
would you use fast but hackish C-style code
in favor of the convenient STL classes?

You haven't shown that "hackish C-style code" is faster than
the STL code that replaces it.
Would your answer change
if you were forced to use a questionable implementation
(such as, not-so-hypothetically, Borland 4)?

No.
 
S

Stephen Waits

Claudio said:
That this happens in some -- maybe even most -- cases, doesn't make it a rule

Agree.

We have our own containers that are as good or better than STL (as it
pertains to us).
And specific to their particular code base.

These weren't specific to one code base. These were trends the Xbox AT
Group had noticed after optimizing several years worth of Xbox titles.

Anyway, most of them were dumb (or ignorant) enough that they had no
bearing on code base - they'd have slowed just about anything to a crawl.

--Steve
 
M

Mabden

Default User said:
Since when does the boss have to prove things to subordinates?

Christopher is the one who wants to introduce changes to the code base,
it's up to him to program it both ways and perform benchmark testing on
it. A nice boss would let him try that on company time, a hardheaded one
would suggest that weekends are made for such experiments.

I had a Boss once that explained the situation quite succinctly, "Don't do
work that doesn't show."

If you're not adding changes the user demands, then what are they paying you
for? Plus, any change can introduce bugs...
 
T

Thomas Matthews

Default said:
Since when does the boss have to prove things to subordinates?

Christopher is the one who wants to introduce changes to the code base,
it's up to him to program it both ways and perform benchmark testing on
it. A nice boss would let him try that on company time, a hardheaded one
would suggest that weekends are made for such experiments.



Brian Rodenborn

Thanks, Brian.

Unfortunately, I also have Christopher's attitude. I was nearly put on
probation for creating a new design when the team (company) said just
document the old code. Now, I know that I can do new designs as long
as I do the old stuff first then prove that my new stuff will benefit
the company more than the old stuff.


--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library
 
T

Thomas Matthews

Christopher said:
Yesterday I changed some code to use std::vectors and std::strings
instead of character arrays. My boss asked me today why I did it, and
I said that the code looks cleaner this way. He countered by saying
that he was regarded the dyanamic allocation that C++ STL classes
perform as being very inefficient. He also said that he wasn't
particularly interested in clean code (!). My question to the group:
In what situations, if any, would you use fast but hackish C-style
code in favor of the convenient STL classes? Would your answer change
if you were forced to use a questionable implementation (such as,
not-so-hypothetically, Borland 4)?

In embedded systems, we try not to use the Compiler's libraries unless
we have plenty of code space and variable (RAM) space. Many
applications have very little RAM to play with, so don't have a "heap"
or dynamic memory. Using the STL as it comes (with generic allocators)
would cause problems.

However, perhaps using the STL with custom allocators _may_ be a
safer route. I don't know on this part because the prevalent attitude
is not to use C++ in embedded systems. :-(


--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library
 
D

Default User

Thomas said:
Default User wrote:
Unfortunately, I also have Christopher's attitude. I was nearly put on
probation for creating a new design when the team (company) said just
document the old code. Now, I know that I can do new designs as long
as I do the old stuff first then prove that my new stuff will benefit
the company more than the old stuff.


Right. Do your research and learn to present it in a way that the boss
doesn't become defensive.

Now, if you happen to be in a situation like I am currently, doing
software R&D, then exploring alternatives is generally encouraged. Even
if it turns out that what you tried blows, at least there's a datapoint
for the next time some bright young (ha!) engineer has the same idea.

I also have a boss who's not a software person, so she doesn't have
ideas about how things should be programmed. Of course our tech lead
does.

It all depends on your situation.



Brian Rodenborn
 
D

Default User

jeffc said:
Who said his boss had to prove anything?

Doesn't that flow from the questions I answered? What are those if not
requests for proof?



Brian Rodenborn
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top