Performance of StringBuilder

[Alvin Bruney]

Jon,
them standards of yours are just wayyyyyyyyyyyyyyyyyyyyyyyy to lofty for the
lowly.

a) By concentrating more on the design in the first place than the
details later on, they could probably have gained more performance
anyway.

The fundamental rule of performance, according to John Robin, is that the
code must be up and working correctly. Only then do you performance tune. or
call in the hotshots.

b) By concentrating on simple, readable code instead of code which runs
very quickly, they're likely to have fewer bugs.

same as above

c) Going after performance where it's not needed is just a waste of
effort.

How do you determine that it's not needed? It's extremely subjective isn't
it? The bottom line is the user experience. So go after it where it makes a
big difference to the user. They are the ones buying the product. They
should be happy. Obviously, and i suspect this is rhetorical but i'll bite
anyway, a good performance tuner ignores the portions of code where tuning
will result in an incremental improvement. But you already knew that. I knew
it too so there really wasn't any need to bring it up. It's a given. A good
tuner fishes out her toolkit and sets about finding portions of the code
which are running slow relative to the user experience and makes a judgement
call on whether it's worth going after.

That's not the way it happens though - people try to go after
performance when they really don't need to, and indeed shouldn't due to
the loss of readability which is often involved when going for really
fast code.

Isn't that a balance a good programmer strikes before she goes in? And since
a performance junkie IS a good programmer, she already knew what to touch
and what to stay away from. Probably junkie is a bad word. It suggests
callous disregard for effects stemming from the cause. I hope you didn't
read it that way. how about performance enthusiast?

The order in which I'd develop in an ideal world would go something
like:

1) Write class specification, bearing in mind architectural
performance (often more of a system issue than an individual class
issue)
2) Write class documentation and empty method stubs
3) Write unit testing code
4) Write first pass simple implementation
5) Get that implementation working against all the tests
6) Run system tests (developed in parallel by a separate team,
probably) including performance measurements
7) If system doesn't perform adequately, isolate bottleneck and
optimise

Skeet
that is tooooo lofty. Yes we are taught that in school, but the real world
operates at a tangent to these rules.
I know you aren't suggesting that you work this way because you would
absolutely discourage the mid-level programmer AND the small business owner
looking to employ said programmer.

Here is how it really works.
1 write code
2. make sure it's working
3. any combination of the following
a design
b unit what?
c. first pass/beta/final release wrapped all in one.
4. maybe, depending on time, document

I'm being facetious on the last part so don't get all bent out of shape. But
i venture this is really happening out there.

in short, a deligent professional always weighs the cost of benefit related
to the investment. said professional makes, hopefully, a sound decision
based on the return on the investment.

 

[Daniel O'Connell]

This could go on and on. I'll agree to disagree with you all.

hmmm, that's where you learn to bend a language backward and forward. You
absolutely want to work with hotshots, if only to become a hotshot yourself.
I'll say here that you call in the performance tuners AFTER the good
programmers have written the code and it is working correctly. That's when
you bring in the heavy artillery.

but still, you've made some agreeable points.

Lets redefine shall we. Heavy artillery is powerful, but its not
particularly flexible, it can only really do one thing(even if it is broadly
applicable). So, equating a particular skill with the term good is kind of
wrong headed. Heavy artillery is useless if you just want to take out one
person. Any programmer who is so focused on performance that he can't write
code as readable and simple as his conterparts is not a good *general*
programmer, while he may be a good tweaker. I'd never turn over an
application to a performance tweaker, for example.

 

[Daniel O'Connell]

Blasted overly anxiousposting finger...

yourself.

I meant hotshot in this case more as "a know it all who really doesn't know
it all", in other words, someone who won't work with the team because he
feels he knows better. A programmer that breaks team trends(like always
using for loops) fits this model, IMHO.

Lets redefine shall we. Heavy artillery is powerful, but its not
particularly flexible, it can only really do one thing(even if it is broadly
applicable). So, equating a particular skill with the term good is kind of
wrong headed. Heavy artillery is useless if you just want to take out one
person with out collateral damange. Any programmer who is so focused on

performance that he can't write

code as readable and simple as his conterparts is not a good *general*
programmer, while he may be a good tweaker. I'd never turn over an
application to a performance tweaker, for example.

I also meant to add that I'd not be keen on working on a project headed by
someone woh is not good in general. Be it because they just aren't very good
or because they are so heavily focused on one thing they can't see anything
else(sort of like seeing a tree but missing the forest). The question is can
you be good and only do one thing very well, or is the general term good
only applicable to those that are good in general?

 

[Jon Skeet [C# MVP]]

The fundamental rule of performance, according to John Robin, is that the
code must be up and working correctly. Only then do you performance tune. or
call in the hotshots.

Absolutely. But you've said that you think a good coder is *always*
going after the best possible performance. That's at odds with the
above, because clearly someone's got to write the code to start with -
are you saying good programmers are never the ones to write the working
code to start with?

How do you determine that it's not needed?

By profiling. There's no point in tuning one bit of code to kingdom
come if it's in no way an actual bottleneck.

It's extremely subjective isn't
it? The bottom line is the user experience. So go after it where it makes a
big difference to the user. They are the ones buying the product. They
should be happy. Obviously, and i suspect this is rhetorical but i'll bite
anyway, a good performance tuner ignores the portions of code where tuning
will result in an incremental improvement.

That's not the impression you gave before though - the impression you
gave was that you admired someone who would go through practically
every line of code and make *everything* as efficient as possible,
whatever the cost in readability.

But you already knew that. I knew
it too so there really wasn't any need to bring it up. It's a given.

It's not a given when you've stated the opposite before - including
about yourself:

<quote>
The habits ingrained in me force me to find the most efficient way to
write code.
</quote>

That's not saying anything about making sure you're only interested in
the most efficient code where it's actually needed.

Isn't that a balance a good programmer strikes before she goes in? And since
a performance junkie IS a good programmer, she already knew what to touch
and what to stay away from. Probably junkie is a bad word. It suggests
callous disregard for effects stemming from the cause. I hope you didn't
read it that way. how about performance enthusiast?

That would certainly be better - the "junkie" word was definitely
bothering me. I'm a performance enthusiast - I enjoy tuning a system,
but *only* where needed, *not* everywhere as you'd previously been
suggesting. I *don't* believe that the most efficient code is required
everywhere.

that is tooooo lofty. Yes we are taught that in school, but the real world
operates at a tangent to these rules.

Well, most of it does. Not everywhere though - look at how Eclipse is
being developed and you'll find a lot of those principles in practice.

I know you aren't suggesting that you work this way because you would
absolutely discourage the mid-level programmer AND the small business owner
looking to employ said programmer.

I don't work that way, but I'd like to. I think it's appropriate for
all levels of programmer and all sizes of business (although possibly
not all types - prototyping may be somewhat different, for instance).

Here is how it really works.
1 write code
2. make sure it's working
3. any combination of the following
a design
b unit what?
c. first pass/beta/final release wrapped all in one.
4. maybe, depending on time, document

That really *isn't* how it works on projects I've worked on. The design
has *always* come first, and I *do* document the code as I go along
(parallel to writing the code rather than beforehand, but not
afterwards).

I'm being facetious on the last part so don't get all bent out of shape. But
i venture this is really happening out there.

in short, a deligent professional always weighs the cost of benefit related
to the investment. said professional makes, hopefully, a sound decision
based on the return on the investment.

Yes - and that's entirely different from the kind of attitude you were
espousing before, being "obsessed with performance" etc.

 

[Romain TAILLANDIER]

what an interresting discuss ....

I think the best method is to not wast hours in steril discuss on news
groups
Now you win a few hours per day, wich allow you, as well needed, to upgrade
code performance, or to write documentation

hopes that's help (and that it is write in understable english ... )
ROM

performance junkie == good programmer

I happen to believe that. Here is why. Going after performance implies that
you were a good programmer, otherwise you'd have no base to improve on
performance. You'd lack the theory. You'd lack the coding technique. You'd
lack the fundamental knowledge about optimization to tackle that kind of
thing. You wouldn't know where to start.

It's like saying fighter pilot == a good pilot. How can you sit in a test
cockpit harness if you can't fly well. You have to be a good programmer
first, then you graduate into a performance junkie. How do you expect to
performance tune if you weren't a hot shot to begin with? That's the way i
see it.

It really doesn't matter to me if I'm writing code for the defense
department or for the science school team. The habits ingrained in me force
me to find the most efficient way to write code. So i will replace
stringbuilders with strings (don't quite believe the stringbuilder hype) and
i will not normally write foreach loops instead of for loops. It doesn't
necessarily make my code always run faster than yours, i do it because it's
a good habit to write performant code. I do it because i believe it pays
divends later, but mostly out of habit. Readability is pretty much a given
these days. This is not the days of C++ when a pointer could leave the
screen and walk on the desktop.
--
Regards,
Alvin Bruney
Got DotNet? Get it here
http://home.networkip.net/dotnet/tidbits/default.htm
are

 

[Alvin Bruney]

bouncing ideas off of each other is not a waste. in my case, bouncing ideas
off this group actually helped me pick up unit testing - something i was
hell bent against. at the end of the day, you take what you can from the
newsgroups, and hopefully it should be more than you came in with. it's
called forward momentum.

--
Regards,
Alvin Bruney
Got DotNet? Get it here
http://home.networkip.net/dotnet/tidbits/default.htm

what an interresting discuss ....

I think the best method is to not wast hours in steril discuss on news
groups
Now you win a few hours per day, wich allow you, as well needed, to upgrade
code performance, or to write documentation

hopes that's help (and that it is write in understable english ... )
ROM

 

[Alvin Bruney]

You are suggesting that i changed tunes. No i did not. I maintain my steady
course. full steam a head. i did clarify certain definitions though so my
direction was not perceived as ambiguous.

above, because clearly someone's got to write the code to start with -
are you saying good programmers are never the ones to write the working
code to start with?

i wasn't suggesting it, but i put it out there as subtle as possible. i
imagine a tuner to be somewhat like a chief architect. the go to guy. he
doesn't really write the code. he sips coffee for most of the morning. then
he gets up, puts an 'X' on the spot where the problem is. He gets mega bucks
to do this simple thing, but his role is absolutely vital otherwise the
worker bees would be spending weeks trying to figure out where to mark the
'X'.
that is in keeping with my original statement.

By profiling. There's no point in tuning one bit of code to kingdom
come if it's in no way an actual bottleneck.

we are on equal ground here

That's not the impression you gave before though - the impression you
gave was that you admired someone who would go through practically
every line of code and make *everything* as efficient as possible,
whatever the cost in readability.

you came off with the wrong impression. what sense does it make to optimize
code which has little impact on the user experience? this was a given, i
didn't think i had to spell it out. give me some credit at least.

Yes - and that's entirely different from the kind of attitude you were
espousing before, being "obsessed with performance" etc.

No it's not. I'm still on course her. You came away with the wrong
impression to begin with. I don't think that i have to state fundamental
principles in an argument. for the most part, it should be assumed. it's not
something i will change either.

 

[Jon Skeet [C# MVP]]

You are suggesting that i changed tunes. No i did not. I maintain my steady
course. full steam a head. i did clarify certain definitions though so my
direction was not perceived as ambiguous.

i wasn't suggesting it, but i put it out there as subtle as possible. i
imagine a tuner to be somewhat like a chief architect. the go to guy. he
doesn't really write the code. he sips coffee for most of the morning. then
he gets up, puts an 'X' on the spot where the problem is. He gets mega bucks
to do this simple thing, but his role is absolutely vital otherwise the
worker bees would be spending weeks trying to figure out where to mark the
'X'.
that is in keeping with my original statement.

It's certainly not in-keeping with what I view a good programmer as
though. I want the good programmers I know to be working on the bulk of
the code - getting it working properly, in easily readable and well
thought out code. That makes for much better maintenance. Most of the
time

you came off with the wrong impression. what sense does it make to optimize
code which has little impact on the user experience? this was a given, i
didn't think i had to spell it out. give me some credit at least.

You said you would not normally write foreach loops, using for loops
instead, for example. You made *no* mention of this only being in code
which you'd already discovered to be bottlenecks. Similarly: " i do it
because it's a good habit to write performant code" - again, no mention
of in its place, with readability being the most important thing for
the 95% of code which isn't a bottleneck.

Here's another one:

<quote>
Going after performance depends on your requirements mostly. Other
times, its just that you want to best yourself by writing the slickest,
fastest, smallest, meanest, most performant code. That last part is for
programmer junkies.
</quote>

That's pretty much flat out saying "performance junkies optimise when
they don't need to".

No it's not. I'm still on course her. You came away with the wrong
impression to begin with. I don't think that i have to state fundamental
principles in an argument. for the most part, it should be assumed. it's not
something i will change either.

I suggest you read your early posts in this thread again, and I think
you'll see how easy it is to come away with the impression I came away
with. Even reading it with your clarifications, it still implies that
you admire those who optimise when they don't need to, and to me that
just isn't a good idea, for readability reasons.