Clean code vs. efficiency

[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)?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Karl Heinz Buchegger]

Re: Clean code vs. efficiency

Christopher Benson-Manica wrote:[color=blue]
>
> 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.[/color]

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

In most cases there is next to no difference in execution speed.
[color=blue]
> 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?[/color]

Never
[color=blue]
> Would your answer change
> if you were forced to use a questionable implementation (such as,
> not-so-hypothetically, Borland 4)?
>
> --
> Christopher Benson-Manica | I *should* know what I'm talking about - if I
> ataru(at)cybers pace.org | don't, I need to know. Flames welcome.[/color]


--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Julián Albo]

Re: Clean code vs. efficiency

Christopher Benson-Manica wrote:
[color=blue]
> 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?[/color]

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

--
Salu2

[Stephen Waits]

Re: Clean code vs. efficiency

Christopher Benson-Manica wrote:
[color=blue]
> 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)?[/color]

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

[Default User]

Re: Clean code vs. efficiency

Karl Heinz Buchegger wrote:[color=blue]
>
> Christopher Benson-Manica wrote:[color=green]
> >
> > 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.[/color]
>
> Really?
> Has he tried it?
> Does he have some performance data?[/color]


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

[Siemel Naran]

Re: Clean code vs. efficiency

"Christophe r Benson-Manica" <ataru@nospam.c yberspace.org> wrote in message
[color=blue]
> 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)?[/color]

By char arrays, do you mean
char array[200];
array = new char[200]; delete[] array;
array = static_cast<cha r*>(malloc(200u )); free(array);
array = ::operator new(200u); ::operator 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:operator 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.destr oy 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.

[Juergen Heinzl]

Re: Clean code vs. efficiency

In article <c7quih$1om$1@c hessie.cirr.com >, Christopher Benson-Manica wrote:[color=blue]
> 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)?[/color]
[-]
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

--
\ Real name : Juergen Heinzl \ no flames /
\ Email private : juergen@mananna n.org \ send money instead /
\ Photo gallery : www.manannan.org \ /

[Stephen Waits]

Re: Clean code vs. efficiency

Siemel Naran wrote:[color=blue]
> In general, the STL containers are extremely fast, and might be faster than
> your home-grown containers due to specializations , fancy algorithms, etc.[/color]

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.
[color=blue]
> But also be aware that usage of STL does not automatically mean your code is
> cleaner.[/color]

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

[Claudio Puviani]

Re: Clean code vs. efficiency

"Stephen Waits" <steve@waits.ne t> wrote[color=blue]
> Siemel Naran wrote:[color=green]
> > In general, the STL containers are extremely fast, and might be faster than
> > your home-grown containers due to specializations , fancy algorithms, etc.[/color]
>
> 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.[/color]

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.
[color=blue]
> He also mentioned lots of other mostly retarded things they'd found.
> Most were unbelievable stupid, but that's OT.[/color]

And specific to their particular code base.
[color=blue][color=green]
> > But also be aware that usage of STL does not automatically mean
> > your code is cleaner.[/color][/color]

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

Claudio Puviani

[E. Robert Tisdale]

Re: Clean code vs. efficiency

Christopher Benson-Manica wrote:
[color=blue]
> 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.[/color]

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.
[color=blue]
> He countered by saying that he was regarded the dynamic allocation
> that C++ STL classes perform as being very inefficient.[/color]

He is almost certainly wrong.
[color=blue]
> He also said that he wasn't particularly interested in clean code (!).[/color]

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".
[color=blue]
> 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?[/color]

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

No.

[Stephen Waits]

Re: Clean code vs. efficiency

Claudio Puviani wrote:[color=blue]
>
> That this happens in some -- maybe even most -- cases, doesn't make it a rule[/color]

Agree.

We have our own containers that are as good or better than STL (as it
pertains to us).
[color=blue][color=green]
>>He also mentioned lots of other mostly retarded things they'd found.
>>Most were unbelievable stupid, but that's OT.[/color]
>
> And specific to their particular code base.[/color]

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

[Mabden]

Re: Clean code vs. efficiency

"Default User" <first.last@boe ing.com.invalid > wrote in message
news:40A11BDD.6 AEFC0F3@boeing. com.invalid...[color=blue]
> Karl Heinz Buchegger wrote:[color=green]
> >
> > Christopher Benson-Manica wrote:[color=darkred]
> > >
> > > 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.[/color]
> >
> > Really?
> > Has he tried it?
> > Does he have some performance data?[/color]
>
>
> 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.
>[/color]

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

--
Mabden

[Thomas Matthews]

Re: Clean code vs. efficiency

Default User wrote:[color=blue]
> Karl Heinz Buchegger wrote:
>[color=green]
>>Christopher Benson-Manica wrote:
>>[color=darkred]
>>>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.[/color]
>>
>>Really?
>>Has he tried it?
>>Does he have some performance data?[/color]
>
>
>
> 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[/color]

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

[Thomas Matthews]

Re: Clean code vs. efficiency

Christopher Benson-Manica wrote:[color=blue]
> 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)?
>[/color]

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

[Default User]

Re: Clean code vs. efficiency

Thomas Matthews wrote:[color=blue]
>
> Default User wrote:[/color]
[color=blue][color=green]
> > 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.[/color][/color]
[color=blue]
> 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.[/color]


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