the cost of intermediate objects

[stevecanfield]

I'd like to know if code like:
long id = obj1.getId();
obj2.someFn(id);

compiles down to:
obj2.someFn(obj1.getId());

I'm thinking it should because it's such an obvious optimization. But
then I'm thinking it can't because I can step through this code with a
debugger and see each statement get executed.

How can I answer this definitively? Is it a matter of looking at the
bytes of the compiled code?

-sc

 

[Daniel Pitts]

I'd like to know if code like:
long id = obj1.getId();
obj2.someFn(id);

compiles down to:
obj2.someFn(obj1.getId());

I'm thinking it should because it's such an obvious optimization. But
then I'm thinking it can't because I can step through this code with a
debugger and see each statement get executed.

How can I answer this definitively? Is it a matter of looking at the
bytes of the compiled code?

-sc

It actually works the other way around, a result has to be "stored"
before it can be passed. In either case, its *not* an optimization
worth worrying about in your code.

The truth is that you should use the second form because it has less
interaction with the surrounding context. If you use:
long id = something;
then "id" is now part of your context. Also, if someone gets the great
idea to reuse id, then it becomes harder to maintain down the road,
because you have to stop and think if which value of "id" are you
looking at.

In other words, when practical you should inline local variables to get
a more "functional programming" approach. If you reuse a lengthy
calculation, you might then save it in a *final* declared variable then
(and only if a profiler tells you that you should).

To answer your original question, don't bother looking. Chances are its
not going to make a significant change to your programs speed.

Oh, and "long" isn't an object, its a primitive value.

 

[Lew]

To answer your original question, don't bother looking. Chances are its
not going to make a significant change to your programs speed.

Oh, and "long" isn't an object, its a primitive value.

First of all, the compiled code is not a complete answer, because it isn't
compiled code exactly, it's compiled bytecode. Bytecode in turn gets
interpreted and compiled at runtime, and the compilation at runtime varies
with the optimizer, and with whatever is going on in the code at the moment
while it's running. So, in fact, any particular optimization (such as your
inlining) might occur sometimes while the program is running, but not at other
times.

Second, no language, Java, C, C++ or whatever, emits much optimization in
debug mode, for the very reason that that would prevent you from stepping
through the code. Debug mode and optimized mode are antithetical.