Ulf Dittmer wrote:The 2nd approach should be faster, but whether that makes a noticeable difference depends on how complex the getMyObject method is.
visually I like more the getter.
as for performance I don't know.
I guess the get takes more time since it's a method.
but the variable is something that is created and remains more time occupying memory so I'm not sure.
To compare the two versions you must assume that "getMyObject()" returns the same object every time you call it. If that isn't the case then the two versions don't necessarily do the same thing.
Joined: Sep 14, 2011
Paul Clapham wrote:To compare the two versions you must assume that "getMyObject()" returns the same object every time you call it. If that isn't the case then the two versions don't necessarily do the same thing.
We had this discussion about this on a performance lecture I held. There are no significant difference.
Our test program did the same test 100.000 times on the "get" approach and then on the "by reference" approach. Running this a couple of times on each students computers (12 students, 3 different OS, quite a large spread on the CPU speed) we found out that in average, the getter approach is 0.0043% faster... That is on average about 100 nanoseconds.
I assume that the compiler and the JVM does some magic with replacement so that the actual code that are run are more or less the same.
I make that assumption based on a profiling we did. The program spends virtually no time in the getMyObject()-method. I assume that the lookup of the reference takes more or less the same time.
From a readers perspective, I tend to like the second approach better, since that shows me directly what type I am working with. With the first approach, I need to look what the method call is returning. But that is just a personal preference.
Joined: Jun 27, 2011
sebastian aguirre wrote:but the variable is something that is created and remains more time occupying memory so I'm not sure.
MyObject will be local variable inside your method and memory will be allocated on stack to hold object reference which will be deallocated once thread is out of method. This assignment will not allocate entirely new memory on heap for object.
[ UD: Edited to fix the incorrect quote tag that attributed text to someone other than the actual author. Please be more careful when quoting people. ]
Joined: Sep 26, 2011
At least in theory, 2nd approach is better. In faculty I learned that in huge loops (100000 for example) it would be better, to keep procedures calls out as much as possible, and instead use a variable containing the result. Then, when I studied assembly language I learned why: a procedure call, takes longer to complete, than just reading a value from a memory location.
The former also involves more steps to complete than the latter:
1. breaks the current execution flow
2. store the current instruction address
3. call the procedure and execute the instructions within
4. write back the result in memory
5. restore the next instruction address so the execution flow can continue
6. read the result returned from function (or generically called procedure)
...this being executed in every iteration
2nd approach in which only the reading step is performed every time, the rest of them, just one time.
But, as Ove said, the difference is almost insignificant, due to current CPU frequencies, bigger caches, faster memories etc. Also the 2nd version is more elegant, as you can actually see the object.