my dog learned polymorphism*
The moose likes Performance and the fly likes Initializing class members to null improves performance ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Performance
Bookmark "Initializing class members to null improves performance ?" Watch "Initializing class members to null improves performance ?" New topic
Author

Initializing class members to null improves performance ?

Horaci Macias
Ranch Hand

Joined: Nov 08, 2001
Posts: 74
Recently I had a discussion with a friend. He told me that initializing class members to null made things run faster, i.e. he said that
<pre>
public class Foo{
private java.util.HashMap map = null;
(...)
}
</pre>was faster than
<pre>
public class Foo{
private java.util.HashMap map;
(...)
}
</pre>
However, I know class members are always initialized, so I don't think it really will run faster. I've made some tests but I found no timing differences between both solutions. Could someone give me a clue?
Thanks in advance,
Horaci Macias

[This message has been edited by Horaci Macias (edited November 20, 2001).]
Peter Haggar
author
Ranch Hand

Joined: Jan 03, 2001
Posts: 106
Your friend is wrong. All instance variables are initialized to their default values when the object is created. If you have code that sets these values to their default values again, you risk wasting time doing it twice. I haven't seen a static compiler optimize these unnecessary assignemtns away, but I would hope JIT and Hotspot do.
Peter Haggar
------------------
Senior Software Engineer, IBM
author of: Practical Java


Senior Software Engineer, IBM
author of: Practical Java
raj sekhar
Ranch Hand

Joined: Oct 16, 2001
Posts: 117
On the contrary does null values assigned for the variables declared inside the methods(which are needed to be initialised) will have better performance since if they are not used they get garbage collected faster?
Thanks
Raj
Horaci Macias
Ranch Hand

Joined: Nov 08, 2001
Posts: 74
I don't think so, because what kind of garbage collector will occur to variables you haven't used ?
If you haven't used them, they are not consuming memory, so garbage collector has nothing to do with them.
On the other hand, I think if you use a variable, and later you set it to null maybe this could help garbage collector if it occurs before leaving the current method (because when you leave a method all variables get out of scope, so they can be garbage collected without performing any operations)
Does anybody agree with me?
raj sekhar
Ranch Hand

Joined: Oct 16, 2001
Posts: 117
When I said 'used' I mean with ref to the following example:
String abc = null;
String xyz = 'something';
assumed that both abc and xyz are not used but just initialised in a method and when gc gets invoked, arent there more chances for abc to be cleared up rather than xyz ? And I am completely wrong in making any assumptions off gc, correct me.
Thanks
Raj
Horaci Macias
Ranch Hand

Joined: Nov 08, 2001
Posts: 74
In your example,

String abc = null;
String xyz = "something";

you've got in memory the data "something" and two String references, one pointing to null (abc) and another (xyz) pointing to the data "something". When gc get invoked, it looks for data in memory not pointed by anything, in the example neither xyz nor abc would be garbage collected (assuming that you are still in the method where abc and xyz are defined). When you leave the method, referenced abc and xyz get out of scope. Data in memory "something" is not pointed anymore by xyz (assuming that nobody else is using that data) so that piece of memory which is not pointed by any reference could (and should) be gc.
You would get the same effect if you place
xyz = null;
before leaving the method. If gc is invoked after setting xyz to null, then "something" will not be pointed anymore by anything (assuming that nobody else is using that data) and again gc could (and should) be gc.
I hope you understand me, english is not my natural language.
Is here any sheriff, bartender, or gc expert that could confirm this explanation ?
Thank you
Horaci Macias
[This message has been edited by Horaci Macias (edited November 21, 2001).]
Peter Haggar
author
Ranch Hand

Joined: Jan 03, 2001
Posts: 106
Horaci's explanation is essentially correct.
Peter Haggar
------------------
Senior Software Engineer, IBM
author of: Practical Java
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
I hope this extra discussion may help understanding (or, if I'm wrong, someone may help my understanding by correcting me!).
In the example, abc and xyz are object references, local to the method in which they are declared. They are not stored on the heap. They are stored on a stack. Things on a stack are not garbage collected. Their lifetime and scope have a constant relationship, defined at compile time.
The object references abc and xyz may refer to objects, or they may refer to no object (null). Any object to which they refer will (always?) be on the heap.
The lifetime of an object on the heap cannot be determined at compile time. An object on the heap needs to stay alive, so long as there is at least one object reference that refers to it. Once no object references refer to it, it becomes eligible for garbage collection.
For performance, it is generally a good idea to avoid having object references referring to objects unnecessarily, as this may delay garbage collection of the objects. Therefore, as soon as an object reference no longer needs to refer to an object, it should be set to refer to no object (null).
In the case of a local object reference, like abc or xyz, it may be "overkill" to set it to refer to no object (null), if the local object reference is about to go out of scope, anyway. It won't do any real harm, but may make code longer than necessary.
An object may be referred-to by object references that are fields of other objects, rather than by local object references, like abc or xyz. These should also be set to null, as soon as the reference becomes unnecessary.


Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Horaci Macias
Ranch Hand

Joined: Nov 08, 2001
Posts: 74
I think you're right Peter Chase. I heard that local variables were stored on a stack, but I didn't know that objects on the stack are not garbage collected.
Even if VM goes out of memory aren't local variables garbage collected ?
I think I've got some books that explain how gc works... I'll look for them, if anyone could help me ....
Thank you,
Horaci Macias
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Horaci, don't get confused... variables allocated on the stack don't get garbage collected (their lifetime is directly associated with the application structure, and they get allocated and deallocated as you enter and exit methods). But they are not objects.
If you have a local object reference (Foo bar = new Foo() ;) then the reference (bar) will live on the stack, but the object it refers to (Foo) will live on the heap and be subject to garbage collection.
What would normally happen is this: as you exit the method, the reference (bar) is automatically deallocated. Unless you assigned the Foo object to another variable, it will become eligible for garbage collection and sooner or later it will be finalized and collected.
If your method takes a long time and a lot of memory to execute it can be advantageous to set "bar" to null as soon as you are finished with the Foo object. Most of the time it's not worth it though, and refactoring the code that deals with Bar into a separate method is often a better option anyway.
- Peter
[This message has been edited by Peter den Haan (edited November 22, 2001).]
Horaci Macias
Ranch Hand

Joined: Nov 08, 2001
Posts: 74
Thanks Peter den Hann, you're right, I began getting confused. I thought from Peter Chase words that every allocation made inside a method could not be gc, so I wrote a piece of code to test it:

I executed this code with -verbosegc option and I noticed that there was a relation between MAXSIZE and the number of objects garbage collected: when I created 2 arrays with MAXSIZE 1000 gc collected about 2000 objects, and when I created 2 arrays with MAXSIZE 2000 there were 4000 objects gc....
Your final explanation makes me feel less confused; although local object references live on the stack, the object it refers to is on the heap, and subject to be garbage collected (when not referenced by any object reference).
Thank you again both Peter (den Hann and Chase) and raj sekhar, I found this discussion very interesting and useful.
Regards,
Horaci Macias
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
Sorry if my explanation was not clear. I probably should have made the distinction between an "object reference" and an "object" more clear. Hopefully, I used these terms correctly, but shouldn't assume my reader interprets them the same as I do!
Anyway, I am glad all is now clear.
Colin Kenworthy
Ranch Hand

Joined: Aug 06, 2001
Posts: 88
Please see this earlier discussion on GC as applied to String.
http://www.javaranch.com/ubb/Forum33/HTML/004107.html
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Initializing class members to null improves performance ?