aspose file tools*
The moose likes Performance and the fly likes best way to call methods in a class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "best way to call methods in a class" Watch "best way to call methods in a class" New topic
Author

best way to call methods in a class

Suman Mummaneni
Ranch Hand

Joined: Dec 14, 2004
Posts: 87
Hi guy,
I have class from which I have to call methods can you confirm which are the best way to do it.
Class A and B are classes available


Suman Mummaneni
Bangalore
India
steve souza
Ranch Hand

Joined: Jun 26, 2002
Posts: 860
This is primarily a style issue, not a performance issue.

One advantage of assigning to a temporary variable (B b = a.test()) is that if you step through a debugger you can explictly see the variables value. Another advantage in my opninion is that if you call one method on an instance and later add calls to other methods the approach above looks cleaner (vs repetitive calls to a.test().doB()). If you did the second approach you would have to change existing code if you switch to (b.doB()) approach, however you wouldn't have to change existing code if you did the opposite switch.

Also, in some cases by assigning to a temporary variable you can make it clear what the particular instance will be used for. Here is an example.

A a = new A();
MyClass colorHolder=a.getHolder();
Color color=colorHolder.get(i);


That is more descriptive (though less abstract) than the following:
A a = new A();
Color color=a.getHolder().get(i);


Note also you can get a null pointer exception in this case if getHolder() can return a null.

Having said that I am consistent in doing this myself, so I would be interested in hearing advantages/disadvantages from others.
[ March 27, 2008: Message edited by: steve souza ]

http://www.jamonapi.com/ - a fast, free open source performance tuning api.
JavaRanch Performance FAQ
Suman Mummaneni
Ranch Hand

Joined: Dec 14, 2004
Posts: 87
Hi Steve,
I think following the example 1 we would have to explicitly set the value to null to start garbage collection once the variable is not used. But this is still a style issue
steve souza
Ranch Hand

Joined: Jun 26, 2002
Posts: 860
That is a local variable, and so is very short lived. Assigning a null to the object is definitely a case of premature optimization.
Suman Mummaneni
Ranch Hand

Joined: Dec 14, 2004
Posts: 87
Well you are right in one case its a local variable. But the method may not exit soon depends on the processing that method has to do. We might need to do a GC some times before we can exit a method.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
There may be rare cases where this makes a significant difference, but in general it's a waste of time to null out local variables. I wouldn't bother with it unless I had evidence that it made a difference in the particular case I was dealing with. Local variables just don't last long enough to make it worthwhile. And as of JDK 6, escape analysis means that many objects referenced by local variables will be cleared automatically when the method exits anyway, without waiting for regular GC. It's better to just keep the code simple and concentrate on the important things, letting the JIT and GC handle the details that they're good at.


"I'm not back." - Bill Harding, Twister
steve souza
Ranch Hand

Joined: Jun 26, 2002
Posts: 860
I'd rethink my design before depending on nulling out an object to trigger it to be garbage collected.
Ben Bos
Greenhorn

Joined: Feb 26, 2008
Posts: 1
I just happened to come across this conversation. I am not a seasoned programmer, but doesn't garbage collection only operate on heap memory?
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[Ben]: doesn't garbage collection only operate on heap memory?

Yes, but local variables can prevent garbage collection as long as the method (or block) has not completed yet. Steve and I are saying that this effect is pretty unimportant, since methods always come to an end eventually, usually pretty quickly, so any delays in GC due to local variables are usually fairly minor.

Also, as of JDK 6 some objects may be stored on the stack rather than the heap. This is generally only done if the JIT can determine that object is only referenced from within the method that created it, and therefore it is guaranteed that when the method completes, the object is no longer needed. One could argue that this is a form of garbage collection, and it uses the stack rather than heap. Basically, as of JDK 6, you often won't know for sure whether an object is on the stack or heap, and you're generally better off not worrying about it.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: best way to call methods in a class