-
1. Re: Code analyze
starksm64 Sep 30, 2006 5:17 PM (in response to alesj)Why bother with such trivial changes, and what is the benefit of it? For all I know hotspot can remove these so I doubt there is any performance issue.
-
2. Re: Code analyze
alesj Sep 30, 2006 9:19 PM (in response to alesj)Hmm .. you're definitely right, as the hotspot code reducing goes.
Just asking if anyone is bothered by the change - I'm a minimalistic code person - so I don't want to step on anybody's toes. -
3. Re: Code analyze
adrian.brock Oct 2, 2006 7:22 AM (in response to alesj)Certainly, in most cases, if the JIT can't optimize to a cpu register,
it will reintroduce the temporary anyway.
That is true even if you don't use a temporary in your code.
The optimization to a register (rather than a stack entry)
will be done regardless of whether the temporary is explicitly declared.
However, with most modern cpus it makes no real difference
since the memory (for smallish methods) will be cached on the cpu.
Making it nearly as fast as registers anyway.
I'd imagine that hotspot removes unncessary cases if it is JIT compiled?
If it is not JIT compiled then it doesn't need optimization.
But the unncessary cast does make the code harder to read. -
4. Re: Code analyze
adrian.brock Oct 2, 2006 7:28 AM (in response to alesj)In general only make these changes if it improves the
readability/maintainability of the code.
e.g. removing dead/unnecessary code gives less to maintain
in future.
Removing temps doesn't change the semantics of the code
so it doesn't really change anything.
In some cases, temps are more optimal.
e.g. code that doesn't use a temp that should:doSomething(getSomethingLotsOfWork()); doSomethingElse(getSomethingLotsOfWork());
Also temps are useful for tracking down NPEs.object.getSomething().getSomethingElse();
should betemp = object.getSomething(); temp.getSomethingElse();
So you know which part was null when you've only got the line number.