• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Strings

 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, it does help. Thank you.
 
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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).
 
Ranch Hand
Posts: 925
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 618
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Are you okay? You look a little big. Maybe this tiny ad will help:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic