Programmers agonize over whether to allocate on the stack or on the heap.
Some people think garbage collection will never be as efficient as direct memory management, and others feel it is easier to clean up a mess in one big batch than to pick up individual pieces of dust throughout the day. This article pokes some holes in the oft-repeated performance myth of slow allocation in JVMs.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:"final makes it 100% clear that the variable's value cannot (and should not) change."
Yes and a programer is forced to use it for any sort of optimisation, this is silly when it is bleedingly obvious that some code can be converted into a constant or optimized away without the forcing the user to write a keyword.
Member since:2005-06-30
> It is implementation dependant.
No kidding. The point is that the Java compiler is primitive, and that's precisely what he was criticizing.
The entire point of an optimizing compiler is to generate the most efficient code the compiler can determine is correct.
You're not relying on anything, because code steam A and code stream B are functionally identical. One is more efficient. Your attitude is "worse code is better, because that's what javac generates."
Member since:2005-10-08
"No kidding. The point is that the Java compiler is primitive, and that's precisely what he was criticizing."
How many times do I have to say I was not referring to Java. I was refering to the fact that it may not exist in Java, but it doesn't really matter if it exists in C or C++ either since it is implementation dependant in C and C++. You are relying on an optimization that may or may not exist depending on what compiler your program is built with. And that is bad style when there are other ways to do it that gurarantee it will be optimized.
And no, the Java compiler is not primitive. It is quite a bit more advanced than gcc. And many optimizations are not done at compile time because they can be done better at runtime. That's the beauty of the virtual machine.
Member since:
2005-10-08
"ANSI/ISO C has nothing to do with Java byte code, and I`m certainly not saying the example I used was for some sort of IFDEF or some such but you can clearly see that this is the_right_thing_to_do TM for normal code."
I know it doesn't. But it sounded like you were implying that a C / C++ compiler would optimize that away, where as a Java compiler will not. What I was saying is that may or may not be true in a C or C++ compiler. It is implementation dependant.
"As for self documenting code you should never care what the binary result is, only that the code is clear enough to understand and final does not always fit."
A variable that is intended to be constant should be declared as such. How can you say final does not always fit? final makes it 100% clear that the variable's value cannot (and should not) change.