Comments on: About the Virtue of Not Improving Performance

By: StringBuilder is not always faster - Part 2 » Chinh Do

StringBuilder is not always faster - Part 2 » Chinh Do — Sat, 29 Sep 2007 06:20:00 +0000

[...] has written a post detailing string.Concat here. Thanks, AJ, for pointing it [...]

By: Chinh Do

Chinh Do — Wed, 19 Sep 2007 16:34:17 +0000

Thanks for the info re string.Concat. Yes I agree that there is such a thing as over-optimization. You have to weigh your optimizations against time lost, harder to understand code, and higher long-term maintenance.

By: Ocho Cinco

Ocho Cinco — Sat, 30 Jun 2007 18:15:38 +0000

Oops, irony storm level 5? (stolen from another blog you might know talking about Paris H.)

Well, I guess you are a smart guy who knows what he is doing (no irony). You might be using your tools in a more “advanced” way (hey, still no irony) than other users (who might prefer “programming with pictures” based on their skills). Maybe some guidelines and tools are simply targeted towards such an audience?

Virtuals: The collections in .Net 2.0 are a framework widely used and something like that should be tuned for a good run-time rather than a better design-time performance. And that library looks quite sexy to me.

Virtuals 2: Less advanced users are easier helped with “automatic” optimizations (compiler, JIT) – that can yield terrific gains (I strongly believe the guys building the JIT know what they are doing – stupid thinking, I know). Virtuals hamper that, because such functions cannot be inlined. So you hurt yourself. Ouch. But at least the Class diagram looks smooth. Congrats!

Sealing your classes:
Doing things implicitly sucks in my eyes, doing things explicitly is king. And based on some mechanisms which changed from Netfx2 to netfx3 it looks like other people are thinking the same. If you want an extension point, say that you want an extensions point. Otherwise, no extension points by default. If you think that this means I like Honecker, go for it. I mean, most classes are never derived from.

foreach: Using foreach on an array for example has almost no overhead. And Rico never said that you should never use foreach:-)

And regarding Microsoft: when you got some 70.000 emps, surely you going to end up with a pretty high number of “so-so”s, as I would call them. And the worst thing is, such people rule the world. And that really hurts. Ouch.

How do you like Linq? (still no irony. Am I getting old?)

By: ajdotnet

ajdotnet — Sat, 23 Jun 2007 10:11:14 +0000

@Ocho
Your first point: I never said that there is no performance gain in avoiding virtuals and I didn’t even mention generics. Actually I like generics for their type safety and clean class design does _not_ mandate virtual methods. Anyway, this is not the point. Someone (Microsoft actually) says you should seal or avoid virtual methods and they say you should do that for performance reasons. My stance is that perfomance may be something to consider but I refuse to let it dictate (to the point of spoiling) my class design. If in certain cases generics are an alternative approach that serves clean design and performance at the same time, great.

Point 2: So you are saying that having the option to do something will lead to the abuse of that feature, therefore only permit that option in certain cases? And you the one to decide? Reminds me of communism, and the party to decide what people should be allowed to do. No thanks, I’ll stay in the free part of the world and live with the consequences.

Last point: Why, from the microsoft hell that is. But there _is_ a chance that they don’t know what they are talking about. You still might want to have a look at the msdn reference I gave, they also provide ample reasons for their suggestion. Personally I haven’t tested .NET 2.0 but with 1.x the overhead definitely was noteworthy; calling the enumerator, casting with type check, IDisposable awareness; these things simply don’t happen automatically with for loops. Whether this will have a noteable effect certainly depends on the collection.

NOI
AJ.NET

By: Ocho

Ocho — Sat, 09 Jun 2007 20:11:50 +0000

Regarding the “sealing virtual methods” and “Consider the Tradeoffs of Virtual Members”: Did you ever take a look why the hell generic collections perform (in many cases) better (read “faster”) than the non-generic ones? Main reason are not the removed casts/(un)boxing (unboxing is very cheap) but the methods are no longer virtual hence the reduced indirections hence the performance gain. And based on a clean design these methods should be virtual, but they are not. Performance trade-off. I like it. It was the right way to go.

Regarding the “sealed” at all: I never understood why classes are not sealed by default. This is the design decision I will never ever understand. People create ridiculously complicated inheritance hierarchies for extensions that never happen because everybody happens to be a great architect these days? Think again.

And where the hell did you get the “Use for loops rather than foreach” suggestion from? That is definitely not correct. foreach can surely beat a for loop in many cases. And many for loops beat foreachs:-)

Cheers.

By: Ray Booysen

Ray Booysen — Fri, 25 May 2007 22:34:48 +0000

Don’t forget String.Format() internally creates a string builder anyway.

By: James Curran

James Curran — Fri, 25 May 2007 15:03:36 +0000

May favortie example of StringBuilder abuse (seen dozens of times)
string A = “….”;
string B = “….”;
StringBuilder sb = ….
// :
sb.Append(A + B);

SO, let’s see… We’ve used a StringBuilder to avoid a string concatenation, and then we do one anyway…..