This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Erap: I read somewhere that it is not advisable to have a new string declaration inside a for-each loop for performance issue. It's because of the String pooling.
Well there is no such hard and fast rule and it entirely depends on the logic, if a new String is required for each iteration then there is no way to avoid it. If you are re-initializing the same object again and again in a loop then it does not make sense irrespective of whether it is a String or not.
You'd have to post the code, for people to be able to comment sensibly.
In general, if a value is invariant throughout a loop, then performance may be improved by calculating and assigning that value outside the loop, rather than inside. How much it is improved depends on what is being done; again, we'd have to see your code to be able to guess.
Against the above, though, is the principle of declaring variables in the smallest scope that they need, and keeping declaration close to use. This makes code more readable. It also helps GC.
Because the vast majority of code has no noticeable effect on performance whatsoever, I would advise you to write your code with clarity, rather than performance, in mind. So, if it's clearer with the String assignment inside the loop, do it that way. At least until: -
Your programs is proven to be too slow, and
The loop in question is proven, by careful measurement, to be a significant piece of code, affecting performance
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
I may be wrong about this, but the smallest scope got me thinking. I declared a string within that scope; guess what it was referred to by string pool, so how will it be garbage collected if i exit out of the loop, granted the referring local reference is removed ... but not the string pool reference.
In general i would advice people to use concat ( '+' sign i meant ) in a for loop, this causes sBuffer to be created to append two literals (strings, i always say that duh! ) which is a performance and memory hit. I have seen too many people do that i their logging of methods ...
Just avoid it.
And anyways, i am always paranoid enough to make all my strings CONST_ ...
[Anirudh Vyas]: I may be wrong about this, but the smallest scope got me thinking. I declared a string within that scope; guess what it was referred to by string pool, so how will it be garbage collected if i exit out of the loop, granted the referring local reference is removed ... but not the string pool reference.
If it's a literal, the string will never be collected (unless that class that declares is is collected). That's true regardless of where you use the literal. But why does it matter? As a literal, it only gets instantiated once, even if it appears in a loop.
[Anirudh Vyas]: In general i would advice people to use concat ( '+' sign i meant ) in a for loop
I think there's a missing "not" in this sentence, based on what you say next.
There are some ways to use string concatenation with '+' in a loop that are completely performant. But in general I agree with the advice: don't do it unless you know what you're doing.
[Anirudh Vyas]: And anyways, i am always paranoid enough to make all my strings CONST_ ...
I'm not sure what this means. Do you give all your strings names that begin with CONST_?
1) Write the code the cleanest way you can. 2) Profile it 3) if issue optimise it.
The whole String + operator is a can of worms, and allow pointed out all over the place I've not seen many blogs show real world poor performance as opposed to bench marks specifically coded to show the problem.
You say it creates an sBuffer and by that I presume you mean StringBuffer but it doesn't necessarily ... obviously in 1.5 it can create a StringBuilder which is unsynchronized but you'ed have forced it to create a StringBuffer which is, so you've added the cost of sync's in (which should still be a save vs object creation (Though that presumably in a 1.6 can use the new create on stack) particularly on 1.6 if escape analysis kicks in and optimise's out your locks ... and so on and so on etc etc )
... but my main reason for hating statements like always use an explicit StringBuffer rather than + is when less experienced Java programmers see stuff like this they start trying to optimise things like this with StringBuffer ...
where the concatenation occurs at compile time NOT run time i.e. concatenation is instantaneous at run time as they are string literals but way slower if you start creating StringBuffer's to add two literals. I know my example looks wrong as normally the reason for concatentating two such strings is the string are big and it makes the code neater so logging is an area this is sometimes done (not by me :-) ) , equivalent to the C++ "String 1 " " String 2" type thing.
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5