wood burning stoves 2.0*
The moose likes Performance and the fly likes String References and Performance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Performance
Bookmark "String References and Performance" Watch "String References and Performance" New topic
Author

String References and Performance

neha sher
Greenhorn

Joined: Apr 07, 2011
Posts: 7
Hello Friends,

In our project, we are aasigning values that are coming from database to String references as follows
String name = message[1];
String address = message[2]; .......................................upto 30 values;

and then we are using these String references to create an object of bean class using setter methods.

myBean.setName(name);
myBean.setAddress(address);

Bean object can be created using message[] also but perhaps, purpose of this is just to make the code readable.

IS it a good practice? Does this create memory issues because after creating bean object we are not using above String references?
Rupesh Mhatre
Ranch Hand

Joined: Apr 29, 2011
Posts: 35

If these strings are getting created once in while its ok but still Nobody will recommend you this implementation. If you want your code to be more readable and easy to understand please make use of comments like
myBean.setName(message[1]); // name
myBean.setAddress(message[2]); // address

This will help code to be easily maintained.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30596
    
154

Neha,
Compared to the database access time, the String references are too tiny to worry about it. I do find the following to be easier to follow though. Especially if you have thirty things and the bean setter names are self explanatory. I wouldn't add the comments that Rupesh recommends though. It is obvious from the setter names what they are; the comment is redundant.



[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Bhay Zone
Greenhorn

Joined: Jul 13, 2009
Posts: 7
Couple of things

If, after setting the values you were doing some expensive computations (in the same method) AND there are 100s or 1000s of threads executing the same code concurrently, then there could be memory issues. Otherwise I do not see any performance issues.

Just for ease of maintainability, I would do this.

int i=0;
String name = messages[i++];
String address = messages[i++];
..
..
..

Why?
Just imagine if you had to add a color attribute somewhere in the middle of your message array.

Again, in the interest of maintainability, I would provide a constructor to the MyBean class with a String[] parameter. This, so that the semantics of creation of this bean are present in a single location. I would not want the code for populating this bean to be spread throughout the application.

Just my 2 cents.

K Abhijit
Ranch Hand

Joined: Mar 03, 2008
Posts: 88

String name = message[1]; -------------------------------------------------------------------------------------------- refer pt 1
String address = message[2]; .......................................upto 30 values;

and then we are using these String references to create an object of bean class using setter methods.

myBean.setName(name); --------------------------------------------------------------------------------------------- refer pt 2
myBean.setAddress(address);



Please note that @ Ref pt 1 as well as pt 2 you ARE NOT CERATING any String object; your are decaring REFERENCES (pointers) to String Obejct.

String Object is constructed ONLY IF WE USE NEW operator like new String("TEST"); else String INTERN pool is used....
I see NO problem what so ever unless in setXXX(String s) you are creating a String Object using NEW operator.



“The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'.”
Lalit Mehra
Ranch Hand

Joined: Jun 08, 2010
Posts: 384

K Abhijit wrote:

String name = message[1]; -------------------------------------------------------------------------------------------- refer pt 1
String address = message[2]; .......................................upto 30 values;

and then we are using these String references to create an object of bean class using setter methods.

myBean.setName(name); --------------------------------------------------------------------------------------------- refer pt 2
myBean.setAddress(address);



Please note that @ Ref pt 1 as well as pt 2 you ARE NOT CERATING any String object; your are decaring REFERENCES (pointers) to String Obejct.

String Object is constructed ONLY IF WE USE NEW operator like new String("TEST"); else String INTERN pool is used....
I see NO problem what so ever unless in setXXX(String s) you are creating a String Object using NEW operator.




It is not so that String Objects are created only if you use new with the String Constructor ... literal value assignments may also create new String Objects

and yes if messages[1] is not already in String Pool a new String Object will be created


http://plainoldjavaobject.blogspot.in
K Abhijit
Ranch Hand

Joined: Mar 03, 2008
Posts: 88
Actually that's what I meant....may be there was a room for improvement in a stating it; So let me re-iterate

When we DON'T use new operator then INTERN pool is referred and if that LITERAL not found in pool, Object is constructed...

in this case particularly , it would NEVER be the case since all Objects have already been constructed.....

anyway thanks for correction
Lalit Mehra
Ranch Hand

Joined: Jun 08, 2010
Posts: 384

your welcome buddy ...
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

Rupesh Mhatre wrote:If these strings are getting created once in while its ok but still Nobody will recommend you this implementation. If you want your code to be more readable and easy to understand please make use of comments like
myBean.setName(message[1]); // name
myBean.setAddress(message[2]); // address

This will help code to be easily maintained.


I disagree here. The setter's name, setName() is all you should need to know that you are setting the name. the comment of
// name

is redundant and error prone. If your setter names are not clear, fix them. The problem is likely to come up in the middle of a long set of setter calls


myBean.setBirthDate(message[12]); // gender

Here, you have changed which setter you are calling and did not change the comment.


Back on topic for Performance, this seems like a classic premature optimization. The JIT will make all of these the same.
 
GeeCON Prague 2014
 
subject: String References and Performance