Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Strings  RSS feed

 
Allen Thomas
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was looking through some code of my friends and he has this in his program:
//rst is the RecordSet
...
while(rst.next()) {
String tempId = rst.getString("var1");
String tempCd = rst.getString("var2");
//5 other Strings in this loop
}
I had told him that this is not efficient because of the string object in the loop. Am I right? He disagrees with me. Would anyone have a better explanation in why do or not do this type of programming?
Thanks in advance!
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your friend is correct - there is no problem in the code presented.
The typical performance problem attributed to Strings comes from their immutability - every time you change a String, you actually create a new one (which causes some overhead and might let the GC run more often).
If the *same* String is manipulated in a loop, you can possibly get a performance advantage by using a StringBuffer instead.
As there are no operations performed on the Strings in the code example, there is also no overhead involved.
Did that help?
[ July 03, 2003: Message edited by: Ilja Preuss ]
 
Allen Thomas
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, it does help. Thank you.
 
David Weitzman
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you're wondering if

would be better than

the answer is no. The two compile to identical bytecode (except for debug info, of course).
 
SJ Adnams
Ranch Hand
Posts: 925
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
how about?
while(rst.next()) {
String tempId = rst.getString(1);
String tempCd = rst.getString(2);
//5 other Strings in this loop
}
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Simon Lee:
how about?
while(rst.next()) {
String tempId = rst.getString(1);
String tempCd = rst.getString(2);
//5 other Strings in this loop
}

Can't be said without looking at the implementation of the RecordSet.
Might of course be a little bit faster. What is more important is that it is also more brittle and harder to understand.
 
Stephen Huey
Ranch Hand
Posts: 618
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:

The typical performance problem attributed to Strings comes from their immutability - every time you change a String, you actually create a new one (which causes some overhead and might let the GC run more often).
[ July 03, 2003: Message edited by: Ilja Preuss ]

Ok, so in another Performance thread, either you or someone else told a guy to burn any book he has that says to use StringBuffer over Strings when it comes to the expensiveness of the concatenation operator. But this Websphere Advisor article talks about how it's a well-known fact that b/c of String immutability, then StringBuffer should often be used over String. Who's right? Do they just not known what they're talking about, and is creating new Strings really just not that much slower? I mean, I think I'll believe you if you say that creating new String objects really doesn't generate that much overhead--I just don't know, and would like to know...
 
David Weitzman
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In that particular article the author is merely wrong. The two code blocks end up being (almost) the same bytecode, and the version without an explicit StringBuffer is easier to read.
The place for explicitly using a StringBuffer is when you're building a String during successive iterations of a loop and the compiler isn't clever enough to make use of a StringBuffer without being asked, or possibly if you know the final string size beforhand and wish to preallocate the StringBuffer to the right size.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are of course situations where using a StringBuffer instead of a String makes sense.
What doesn't make any sense is stating that you should generally prefer StringBuffers over Strings, without discussing when maintainability is more important than performance (which is almost always) and when the "optimization" actually isn't one because of existing automatic optimizations done by the compiler.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!