Optimize code with StringBuilders

boomzilla

If they are the same, why use ++i and create confusion? Because that is the actual point.

Are you certain? I could have sworn that the point was how many people you successfully trolled right off the bat. Well done, you'll fit right in.

Weng

@blakeyrat said:

Not that I'd be able to afford Penn State anyway.

Another advantage of podunk shitville York campus. Like 1/3rd the cost. Still god fucking damned expensive, though. I still owe like $30k+ [i]after[/i] as much financial aid as you could possibly get as an out-of-stater and like $5000/semester in cash.

boomzilla

@blakeyrat said:

1) They became completely obsessed with me learning useless maths (like calculus)

Almost any computational math at the college level is not very worthwhile with respect to programming computers (OBpedanticdickweed: with the obvious exception being programming in a field that needs complex calculations). About the only exception to that is linear algebra, though even that is generally limited to graphics sort of stuff. What is very useful is any sort of abstract math course where you learn by reading and writing proofs. I miss that sort of thing, but for me programming is very similar, so I can get my fix that way.

Sutherlands

@thistooshallpass said:

You make a lot of assumptions, and most of them are wrong.

By "assumption" do you mean "question"? (That's a question, not an assumption)

@thistooshallpass said:

And I would kindly point out that the only person who said that you are a bad programmer is yourself.

ITT: User doesn't understand sarcasm.

locallunatic

@blakeyrat said:

@locallunatic said:
I'd disagree on the calc being useless, it's useful for things in my life (just not programming).

Yes, well, the problem was it was a requirement for the computer science program. Saying "it's useful, just not for programming" doesn't contribute much to the thread.

Sorry I was partially agreeing with you. Part of the reason it's a common requirement for CS is that the department grew out of either the Math or EE departments where it's an understandable requirement. Also it may have to do with most CS degrees being BS rather than a BA (though there are now schools that do both).

@blakeyrat said:

@locallunatic said:
And if they weren't teaching about things like usability then you were in a terrible CS program (though in many that stuff is a little later and optional instead of required like it should be).

I concur, but let me ask: in 1997, what universities taught CS with a focus on usability? I honestly do not think any CS programs at that time did, and I certainly didn't find one at the time. Although I fully admit I could be wrong.

No idea if they did back then I'm a more recent vintage of graduate.

thistooshallpass

@boomzilla said:

@thistooshallpass said:
If they are the same, why use ++i and create confusion? Because that is the actual point.

Are you certain? I could have sworn that the point was how many people you successfully trolled right off the bat. Well done, you'll fit right in.

That was a valid point, and if some people get emotional over this then it's too bad.

Weng

@boomzilla said:

What is very useful is any sort of abstract math course where you learn by reading and writing proofs.

I did one of those classes. Teacher was brand new, horrible, and didn't seem to understand the topic herself. Spent the entire time in the back row with some like-minded hooligans playing Counterstrike on some craptops (and when she got pissed, we'd bust out some pre-printed sudoku puzzles and sit there working those. Logic puzzles, after all, are relevant to the class).

A particular hobby of mine was to stop dicking around, ask an on-topic, fairly simple question and watch her squirm trying to answer it. NEVER got a straight answer the entire semester. Another was to spot the inevitable error in whatever she was working on the board and point it out.

Got an A. Didn't even buy the textbook (indeed, nobody in the elite ranks of the "Room 107 Back row" listserv-o-hooligans owned one)

Sutherlands

Re Math: My CompSci degree required Calc 1/2, Linear Algebra and Discrete Math. Can't say the Calc is particularly useful, but I had that before starting the degree anyway.

@thistooshallpass said:

@boomzilla said:
@thistooshallpass said:
If they are the same, why use ++i and create confusion? Because *that* is the actual point.
Are you certain? I could have sworn that the point was how many people you successfully trolled right off the bat. Well done, you'll fit right in.
That was a valid point, and if some people get emotional over this then it's too bad.

If that was what you said then I would have just said "style" and went on. But no, first you post something about how you don't even understand how it works, and say my code is suspect because of it. Your next post continues with your misunderstanding, and says that because I don't adhere to your coding standards, it's a tell. You made a lot of assumptions, such as that an experienced programmer has to take seconds to process the information before discarding it, which are not true. You also tell us to "avoid personal style" in personal code.

Yeah, you're a troll, whether you're trying or not.

thistooshallpass

@Sutherlands said:

Re Math: My CompSci degree required Calc 1/2, Linear Algebra and Discrete Math. Can't say the Calc is particularly useful, but I had that before starting the degree anyway.

@thistooshallpass said:
@boomzilla said:
@thistooshallpass said:
If they are the same, why use ++i and create confusion? Because *that* is the actual point.
Are you certain? I could have sworn that the point was how many people you successfully trolled right off the bat. Well done, you'll fit right in.
That was a valid point, and if some people get emotional over this then it's too bad.
If that was what you said then I would have just said "style" and went on. But no, first you post something about how you don't even understand how it works, and say my code is suspect because of it. Your next post continues with your misunderstanding, and says that because I don't adhere to your coding standards, it's a tell. You made a lot of assumptions, such as that an experienced programmer has to take seconds to process the information before discarding it, which are not true. You also tell us to "avoid personal style" in personal code.

Yeah, you're a troll, whether you're trying or not.

Yes, a single line of code with a non-typical syntax will just slow down the reviewer a little, maybe not seconds, but still a little. But over the years, the cost of reviewing that single line of code will increase significantly. What about an entire codebase written by two hundred different programmers with all their different preferences and habits? Individual preferences are expensive.

As for me being a troll or not - I think labels are lazy and unfair, and they are telling more about the people who use them than about the people to which they are applied.

Whoa314

@thistooshallpass said:

@boomzilla said:
@thistooshallpass said:
If they are the same, why use ++i and create confusion? Because that is the actual point.

Are you certain? I could have sworn that the point was how many people you successfully trolled right off the bat. Well done, you'll fit right in.

That was a valid point, and if some people get emotional over this then it's too bad.

Ignoring your sly dodge going from "why don't you use a larger start index if you're going to increment it before it's first used (incorrect interpretation of how a for-loop works)" to "that's nonstandard style so it will cause people to look at it strange, thus wasting valuable brain cycles", where I work the pre-increment is standard and the post-increment would be the one wasting brain cycles:

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Preincrement_and_Predecrement#Preincrement_and_Predecrement

Before you dwell on the line "For simple scalar (non-object) values there is no reason to prefer one form and we allow either", my team happens to still adhere to using pre-increment for scalars because there really is a non-trivial distinction in the semantics of the two:

++i: "Just increment it in place (and return a reference in case I want to use the new state of the thing)"

i++: "Give me the current value, and increment the thing, (but make sure the incrementing of the iterator doesn't clobber my current value!)"

Sutherlands

@thistooshallpass said:

Yes, a single line of code with a non-typical syntax will just slow down the reviewer a little, maybe not seconds, but still a little. But over the years, the cost of reviewing that single line of code will increase significantly. What about an entire codebase written by two hundred different programmers with all their different preferences and habits? Individual preferences are expensive.

No, not "a little". None. Also, you need a new standard for "significant". In some things, preference is important to stamp out. That's why we use pascal case for methods and properties, and camelcase for variables. This is not one of those things that's important to stamp out, because the cost is none.

(And as Whoa just pointed out, different standards apply at different places.)

@thistooshallpass said:

As for me being a troll or not - I think labels are lazy and unfair, and they are telling more about the people who use them than about the people to which they are applied.

You're welcome to think what you want, and we're welcome to think what we want.

thistooshallpass

@Sutherlands said:

@thistooshallpass said:
Yes, a single line of code with a non-typical syntax will just slow down the reviewer a little, maybe not seconds, but still a little. But over the years, the cost of reviewing that single line of code will increase significantly. What about an entire codebase written by two hundred different programmers with all their different preferences and habits? Individual preferences are expensive.
No, not "a little". None. Also, you need a new standard for "significant". In some things, preference is important to stamp out. That's why we use pascal case for methods and properties, and camelcase for variables. This is not one of those things that's important to stamp out, because the cost is none.

@thistooshallpass said:
As for me being a troll or not - I think labels are lazy and unfair, and they are telling more about the people who use them than about the people to which they are applied.
You're welcome to think what you want, and we're welcome to think what we want.

I am not sure if you disagree with the cost of non-typical syntax, or if you disagree that the ++x syntax is non-typical, so maybe I am making noise for nothing. This being said, I have to ask - are you an elected spokeperson or are you just more comfortable saying "we" for some other reason ? (Not an assumption - just a question).

thistooshallpass

@Whoa314 said:

@thistooshallpass said:
@boomzilla said:
@thistooshallpass said:
If they are the same, why use ++i and create confusion? Because that is the actual point.

Are you certain? I could have sworn that the point was how many people you successfully trolled right off the bat. Well done, you'll fit right in.

That was a valid point, and if some people get emotional over this then it's too bad.

Ignoring your sly dodge going from "why don't you use a larger start index if you're going to increment it before it's first used (incorrect interpretation of how a for-loop works)" to "that's nonstandard style so it will cause people to look at it strange, thus wasting valuable brain cycles", where I work the pre-increment is standard and the post-increment would be the one wasting brain cycles:

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Preincrement_and_Predecrement#Preincrement_and_Predecrement

Before you dwell on the line "For simple scalar (non-object) values there is no reason to prefer one form and we allow either", my team happens to still adhere to using pre-increment for scalars because there really is a non-trivial distinction in the semantics of the two:

++i: "Just increment it in place (and return a reference in case I want to use the new state of the thing)"

i++: "Give me the current value, and increment the thing, (but make sure the incrementing of the iterator doesn't clobber my current value!)"

Well you don't really ignore the [alleged] dodge if you mention it... which raises the question of who is the sly one here... On the actual point, I still don't agree with your syntax because the same token presents a different behavior in a different context, and I don't need to dig google urls to back something that obvious. (is he pre-incrementing the value? oh no, it's in a for loop, so he is cleverly not clobering the variable!).

Sutherlands

@thistooshallpass said:

I am not sure if you disagree with the cost of non-typical syntax, or if you disagree that the ++x syntax is non-typical, so maybe I am making noise for nothing.

I disagree that the syntax is non-typical in all location, and I disagree that even if it is non-typical, that THIS particular syntax has any cost. I MOSTLY disagree with saying someone's code "smells" because it doesn't follow your personal syntax.

@thistooshallpass said:

This being said, I have to ask - are you an elected spokeperson or are you just more comfortable saying "we" for some other reason ? (Not an assumption - just a question).

I probably should be, but no. I said we because I wasn't the person to initially call you a troll.

Sutherlands

@thistooshallpass said:

On the actual point, I still don't agree with your syntax because the same token presents a different behavior in a different context, and I don't need to dig google urls to back something that obvious. (is he pre-incrementing the value? oh no, it's in a for loop, so he is cleverly not clobering the variable!).

What? The behavior presented by the pre-increment operator is "increase the value". The behavior presented by the post-increment operator is "increase the value, but save the old value". You're trying to say that the post-increment behavior makes more sense to put in a for loop?

boomzilla

@thistooshallpass said:

On the actual point, I still don't agree with your syntax because the same token presents a different behavior in a different context, and I don't need to dig google urls to back something that obvious. (is he pre-incrementing the value? oh no, it's in a for loop, so he is cleverly not clobering the variable!).

OK, who let Spectate get a new account?

Whoa314

@thistooshallpass said:

Well you don't really ignore the [alleged] dodge if you mention it... which raises the question of who is the sly one here...

It's true, I am known to be rather sly.

@thistooshallpass said:

On the actual point, I still don't agree with your syntax because the same token presents a different behavior in a different context, and I don't need to dig google urls to back something that obvious. (is he pre-incrementing the value? oh no, it's in a for loop, so he is cleverly not clobering the variable!).

So, the point of the style guide I linked isn't just the "obvious" difference in semantics in itself, but rather the consequences of the difference in semantics. In particular, the "++" operator is often used for iterator semantics over expensive data types, say for selectively loading pieces of a huge file into memory. Pre-increment gets to do a straight-up write into an existing memory block, while post-increment necessarily requires two segments to be live simultaneously (even if the old one soon gets discarded thereafter); in many real cases, this could result in L1/L2 cache eviction and/or page faults which non-trivially degrade performance.

I should clarify as well, when I review code I don't actually care if people prefer post-increment, unless it is indeed a case where they are using some expensive iterator type. It's just that your particular claim that post-increment is preferable over pre-increment due to the latter being "non-typical" syntax is unfounded for several reasons:

Based on the style guide I linked, plus the responses in this thread, pre-increment is clearly not "non-typical".
Pre-increment is the one that is "sometimes better, but never worse" than using post-increment, so if anything, pre-increment should be preferred over post-increment.
Performance considerations aside, the very meaning of pre-increment ("increment the thing") captures the intention inside the for-loop better than post-increment ("give me the current value, and then increment the thing").

thistooshallpass

@Sutherlands said:

@thistooshallpass said:
I am not sure if you disagree with the cost of non-typical syntax, or if you disagree that the ++x syntax is non-typical, so maybe I am making noise for nothing.
I disagree that the syntax is non-typical in all location, and I disagree that even if it is non-typical, that THIS particular syntax has any cost. I MOSTLY disagree with saying someone's code "smells" because it doesn't follow your personal syntax.
@thistooshallpass said:
This being said, I have to ask - are you an elected spokeperson or are you just more comfortable saying "we" for some other reason ? (Not an assumption - just a question).
I probably should be, but no. I said we because I wasn't the person to initially call you a troll.

When you "mostly disagree", does it mean that you somehow "partially agree" with the remaining of the sentence, or does it mean that the remaining of the sentence is what you disagree mostly with in the whole post? You see, once again confusion would have been avoided if you had put the modifier *after*.

Whoa314

@thistooshallpass said:

You see, once again confusion would have been avoided if you had put the modifier after.

I lol'd.

Sutherlands

@thistooshallpass said:

When you "mostly disagree", does it mean that you somehow "partially agree" with the remaining of the sentence,

How would that work, exactly?

Also, once again, you're the only person confused. (You should probably look into that.)

thistooshallpass

@Whoa314 said:

@thistooshallpass said:
Well you don't really ignore the [alleged] dodge if you mention it... which raises the question of who is the sly one here...
It's true, I am known to be rather sly. @thistooshallpass said:
On the actual point, I still don't agree with your syntax because the same token presents a different behavior in a different context, and I don't need to dig google urls to back something that obvious. (is he pre-incrementing the value? oh no, it's in a for loop, so he is cleverly not clobering the variable!).
So, the point of the style guide I linked isn't just the "obvious" difference in semantics in itself, but rather the consequences of the difference in semantics. In particular, the "++" operator is often used for iterator semantics over expensive data types, say for selectively loading pieces of a huge file into memory. Pre-increment gets to do a straight-up write into an existing memory block, while post-increment necessarily requires two segments to be live simultaneously (even if the old one soon gets discarded thereafter); in many real cases, this could result in L1/L2 cache eviction and/or page faults which non-trivially degrade performance.

I should clarify as well, when I review code I don't actually care if people prefer post-increment, unless it is indeed a case where they are using some expensive iterator type. It's just that your particular claim that post-increment is preferable over pre-increment due to the latter being "non-typical" syntax is unfounded for several reasons:

1. Based on the style guide I linked, plus the responses in this thread, pre-increment is clearly not "non-typical".
2. Pre-increment is the one that is "sometimes better, but never worse" than using post-increment, so *if anything*, pre-increment should be preferred over post-increment.
3. Performance considerations aside, the very meaning of pre-increment ("increment the thing") captures the intention inside the for-loop better than post-increment ("give me the current value, and then increment the thing").

To be honest you kinda lost me in the segments and L1/L2 part, sounds like something that apply mostly to low-level languages, but I have to admit that your last three points are valid. I stand by my position that non-typical syntax should be avoided as a rule, but I'll admit that this very ++x syntax does not appear to fall under the non-typical category, and that while it allowed an interesting discussion, this whole thread that I started was based on my biased preferences.

TROLL THREAD TROLL THREAD YAAAAY

On pre- vs. post-increment: I use pre-increment, the rest of the team uses post-increment and we're all cool with it. I use it because there's a part of my brain which, upon seeing a for loop with post-increment, shouts @black hemisphere said:

POST-INCREMENT! FUUUUUUUUCK! NOW VISUAL C 6 WILL CREATE A COMPLETELY UNNECESSARY ITERATOR VARIABLE ON EACH PASS! CHANGE COURSE! CHANGE COURSE! PRE-INCREMENT! PRE-INCREMENT! AAAIIIIIEEEEE!

and it takes a couple of moments for the rational part to catch up and remind me "shhh it's alright. We're writing java now. This is a number. It's alright."

P.S. Did only I find calculus neat? I got a B without studying too much. When we got to parametric surfaces things went pear-shaped, but entry-level calculus was just fine.

blakeyrat

I have no idea what this thread even is about anymore.

Dungeons of Dredmor is funny and engaging.

OperatorBastardusInf

Here are my comments to the ++i vs i++ topic:

- in C, these two are totally equivalent in that for loop context.
- I know at least one compiler of a C-like language that does generate inefficient code for i++ even in for loop context, and even warns about every single use of post-increment no matter if sensible or not
- in C++, they are very non-equivalent, given that they call different functions:

++i calls

itype itype::operator++()
{
    increment(*this);
    return this;
}

i++ calls

itype itype::operator++(int)
{
    itype icopy(*this);
    increment(*this);
    return icopy;
}

If the operators or copy constructor cannot be called inline, the compiler has no way to optimize out the internal temporary created by the post-increment!

Personally, i++ (postincrement) is the odd one to me, and it should used only if it is sensible. Typical sensible use of it is code like

line = 0;
a[line++] = "first line";
a[line++] = "second line";
while(...)
    a[line++] = "more lines";

boomzilla

@OperatorBastardusInfernalis said:

Here are my comments to the ++i vs i++ topic:

- in C++, they are very non-equivalent, given that they call different functions:

Of course, in overloaded iterators or whatever, there can be a huge difference. In general, in for loops, with some sort of an integer type of variable, however, they are indeed equivalent. Different functions can be equivalent in certain contexts.

blakeyrat

Article somewhat relevant to the issue.

@Al Sweigart said:

Code that is straightforward to read is easy to understand. Code that is easy to understand is less likely to have bugs. Code that is easy to understand is easy to extend with new features. And it’s bug-free programs with cool features that people want. Nobody cares about a few million nanoseconds.

Iago

@blakeyrat said:

Article somewhat relevant to the issue.

Only not really, because the only language where this is really an optimization issue is C++, and I thought we were talking about C# in this thread.

This is purely a style issue, like brace placement or tab width. It really doesn't matter what you do as long as it is the same throughout the code you are working on. When posting examples on the internet, it could not matter less.

Oh, and { should go on the same line as the if/while/for/else, but } should always have its own line; tabs should be four spaces; and for loops should use preincrements. I know this because Jesus told me, and all you sinners are going to bitterly regret your postincremented loop variables when you are burning in HELL.

Lord_abletran

Personally, I just use some inline assembler to increment.

for(int i = 0; i < something;
__asm (
mov eax, i
inc eax
); )

Scarlet_Manuka

Aren't you missing a mov i, eax in there?

Lord_abletran

Well, ideally, you'd write the whole thing in asm, and just leave the value in a register if you could.

Scarlet_Manuka

Registers registers = new Registers;

for (int i = 0; i < registers.count; i++)

{registers[i].Clobber();}

jes

How is post-increment or pre-increment "typical syntax"? Where does this definition of typical come from?

I just did a grep over the C source files in the Linux kernel, granted the grep expression didn't catch every for loop with a pre/post increment, but a quick scan of matched lines suggest that the error margin will be quite low.

Pre-increment - 39993

Post-increment - 3600

SO a little over 10:1 for pre-increment. Does that define it as typical?

A better question would be - if you find the use of one or the other in for loops to be disconcerting, what are you doing performing code reviews when you obviously aren't actually very good with the language? Spend your time reading code and learning, after a while you'll simply stop noticing pre/post increments of loop counters in cases where it's irrelevant.

You posted example confirms my advice that you should be learning code and not reviewing.

blakeyrat

@jes said:

I just did a grep over the C source files in the Linux kernel

QFWTF

thistooshallpass

@jes said:

How is post-increment or pre-increment "typical syntax"? [...]

A few days ago, while you were busy running grep and trying to find a way to express your sense of self-righteousness, someone else (actually a few people) made a compelling argument which led me to recognize my mistake. You are welcome to come after the fact and make the same arguments all over again but since everybody (including me) appears to agree with you, don't expect a heated discussion.

@jes said:

You posted example confirms my advice that you should be learning code and not reviewing.

Based on a single posted example, I made a snide comment to Sutherlands, which allowed a good discussion but turned out to be baseless and unfair. It would appear that this forum offers many learning opportunities...

jasmine2501

@Lorne Kates said:

BUT... how many times are you going to be concat'ing 10000 strings? As it stands, I had to do more than 600 strings just to get the concat loop to take longer than a millisecond.

How many 0.001% performance hits does it take to bring a system crashing to a halt when you deploy it to production and suddenly there's 10K users hammering it? Every performance improvement that doesn't increase maintenance should be done, and it doesn't really matter if it's just a marginal improvement, because you multiply that by how many places you implement the improvement, and how many users hit those lines of code.

blakeyrat

@jasmine2501 said:

Every performance improvement that doesn't increase maintenance should be done,

Before measuring?

@jasmine2501 said:

and it doesn't really matter if it's just a marginal improvement, because you multiply that by how many places you implement the improvement, and how many users hit those lines of code.

Actually, Microsoft's well-known philosophy of "don't bother and let the hardware catch up" worked marvelously for them for many decades. (Not quite as much now, but.)

thistooshallpass

@blakeyrat said:

Actually, Microsoft's well-known philosophy of "don't bother and let the hardware catch up" worked marvelously for them for many decades.

This strategy has reached a peak with their new data warehousing product : SQL 2008 R2 Parallel Data Warehouse. It's your typical SQL Server software... only it comes with a rack of HP blades filled with hig-performance CPUs, loads of RAM and SSD-only storage. Very affordable, should hit Wal-mart shelves soon.

boomzilla

@blakeyrat said:

@jasmine2501 said:
Every performance improvement that doesn't increase maintenance should be done,

Before measuring?

Of course, if you don't measure, then you really don't know if it's a performance increase. And like every other change to software, you have to balance the costs and risks with the benefits. Especially the risk of increased maintenance that you didn't foresee.

@blakeyrat said:

@jasmine2501 said:
and it doesn't really matter if it's just a marginal improvement, because you multiply that by how many places you implement the improvement, and how many users hit those lines of code.

Actually, Microsoft's well-known philosophy of "don't bother and let the hardware catch up" worked marvelously for them for many decades. (Not quite as much now, but.)

There's a massive difference between single user applications and multi-user, of course. Adding a few hundred or thousands of users can easily swamp hardware improvements. And now our hardware improvements have changed a bit in character (more cores vs faster cores), it's not as simple as it used to be.

blakeyrat

@boomzilla said:

Of course, if you don't measure, then you really don't know if it's a performance increase. And like every other change to software, you have to balance the costs and risks with the benefits. Especially the risk of increased maintenance that you didn't foresee.

The reason I prod is that most people who say "optimize everything by default", if you prod, are not actually measuring performance. Or, if they are, they aren't measuring in a holistic manner. "Great, you made that 25ms function run in 15ms... of course it still only runs once per hour."

I can see "optimize everything" to be a good strategy for, say, Twitter. But, again, you gotta be measuring... if you're not measuring you're just wasting time.

boomzilla

@blakeyrat said:

I can see "optimize everything" to be a good strategy for, say, Twitter. But, again, you gotta be measuring... if you're not measuring you're just wasting time.

Totally agree. If you don't notice anything...of course, there are people who only measure on a tiny sample of data or something equally unrealistic. I work with a lot of them. A fair assumption is that anything most of them wrote won't scale well beyond their tiny sample data. And they don't have a clue as to how to speed it up even when smacked in the face with it.

jasmine2501

@boomzilla said:

@blakeyrat said:
I can see "optimize everything" to be a good strategy for, say, Twitter. But, again, you gotta be measuring... if you're not measuring you're just wasting time.

Totally agree. If you don't notice anything...of course, there are people who only measure on a tiny sample of data or something equally unrealistic. I work with a lot of them. A fair assumption is that anything most of them wrote won't scale well beyond their tiny sample data. And they don't have a clue as to how to speed it up even when smacked in the face with it.

This is what I'm talking about. I'm not talking about squeezing every last drop of speed you can get out of things that don't matter to the whole, or doing expensive re-factoring of large codebases for marginal improvements. What I'm talking about is coding for performance in the first place. Programmers today write code as if it all runs infinitely fast and never uses any memory - this is a bad practice. If you know that StringBuilders are always faster/less memory, then you always use them. The place where I see the biggest problem with this is actually in SQL code - too many shops put their VB developers writing stored procs, and you end up seeing more brute-force SQL and fewer elegant set-based operations. The world I live in right now is one in which the primary application I work on was never designed to be used with more than sample data. We can tell from looking at the code that it isn't designed for performance in the first place - so what I'm looking at is thousands of tiny performance problems adding up to be one huge problem for our users. Don't create this problem in the first place and you'll be much better off. Sorry for not being funny.

dhromed

@jasmine2501 said:

Sorry for not being funny.

I'll let it fly this time.

Lorne Kates

@jasmine2501 said:

@Lorne Kates said:
BUT... how many times are you going to be concat'ing 10000 strings? As it stands, I had to do more than 600 strings just to get the concat loop to take longer than a millisecond.

How many 0.001% performance hits does it take to bring a system crashing to a halt when you deploy it to production and suddenly there's 10K users hammering it?

Well, if a system crashes to a halt at 100%, then 10 of them. If all 10k users use all 10 of their performance hits at the same time. Or eleventeen, since we're talking hypothetically.

Every performance improvement that doesn't increase maintenance should
be done, and it doesn't really matter if it's just a marginal
improvement, because you multiply that by how many places you implement
the improvement, and how many users hit those lines of code.

Unless the amount of time you spend coding that marginal improvement is orders of magnitude more than the time it will save. Give me a year with any codebase, and I'll somehow save you a tenth of a second per transaction.

My point is that everywhere I've worked has had "developer rules" addressing performance like "Never concat strings, always use a string builder". All those places also have management who say "I'd rather get it working now than perfect later, because we can make it better later if we need to."

Now me, I'm all for finding places to optimize code and make it better. But I also know that more rules that contain "Never" and "Always" almost never always apply. A string builder is more typing than a concat, and requires a bit more developer brain power to use. Do I care if the sign-in page for 10k users is 0.001% slower? Nope, concat all you want. People will only visit that page once per session (if that, thank you cookies).

But what about the Forum.aspx that renders every forum and forum post and is read 10k times a minute (if not more)-- yes, optimize the fuck out of that page. No holds barred. Optimize it anally. Use japaneese optmizing bondage on it. Make it optimize its own sister on film if that's what it takes.

TheCPUWizard

@Lorne Kates said:

Give me a year with any codebase, and I'll somehow save you a tenth of a second per transaction.

Can I hire you? I have a rather large codebase, and am always looking for improvements, currently transactions process in under 2mS worst case. Once you are done with the code, they should complete at least 98mS before they are submitted. Since this is a financial/trading application, the potential upside is huge.

Lorne Kates

@TheCPUWizard said:

@Lorne Kates said:
Give me a year with any codebase, and I'll somehow save you a tenth of a second per transaction.
Can I hire you? I have a rather large codebase, and am always looking for improvements, currently transactions process in under 2mS worst case. Once you are done with the code, they should complete at least 98mS before they are submitted. Since this is a financial/trading application, the potential upside is huge.

First I'll need a banana, some solder, and a hippopotamus who knows not to ask questions...