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:2005-06-30
> I HAVE written compilers. Have you?
Yes. That's why I participated in this discussion at all, despite not caring even remotely about the output of javac. I don't believe you, though. Your lack of understanding is too complete. Explain how to perform the necessary optimization the original poster desired.
> An optimization that says "this arithmetic operation
> can be done faster if it is bitwise shifted" is one
> thing. This optimizes details that the programmer
> should not be bothered to worry about, and details
> that if the programmer did worry about, would
> decrease code readability.
This contradicts your position that
1) That optimization doesn't provide functionally-equivalent code streams
2) That optimization violates software engineering principles, by performing (provably-correct) transformations that result in code streams you feel should only be provided given sufficient annotation.
> In the case in question, however, you are basically
> asking the compiler to make up for lazy programming,
> and programming that is bad style. That is something
> I am not a fan of. Again, what is your aversion to
> doing it the right way?
All optimization boils down to catering to "lazy programming," where "lazy programming" means not hoisting responsibility for efficiency needlessly to the programmer. Despite that this annotation you're so fond of does _not_ guarantee optimization, it doesn't matter because the programmer doesn't _have_ to worry about providing such an annotation because the compiler can transform the code stream into a more efficient one without any assistance. There is no "aversion" to "doing it the right way," doing it "the right way" is simply unnecessary.
> Wrong. In Java, this annotation does guarantee that
> code wrapped inside a conditional and based on the
> final variable will be removed by the compiler.
No it does not.
Nothing in sections 4.12.4, 13.4.9, 14.21, or 15.28 requires that the compiler not emit code in the presence of such annotations. javac simply happens to implement this as a means of providing conditional compilation in a language without any means of expressing conditional compilation.
> The fact that it is bad style from an engineering
> standpoint and decreases code readability
First, what you have presented is an opinion, not a fact. Second, providing annotations or not providing annotations is irrelevant. The annotation is simply unnecessary for the optimization, and the code stream provided is less efficient. Hoisting responsibility of optimization to the programmer when it is unnecessary is an inferior strategy. That's precisely the stance that HotSpot takes, regardless of what annotations you happen to insert into your codebase.
> decreases code readability
Automatic optimization does absolutely nothing to alter code readability.
> If you want to write crap code that relies on
> compiler magic to make up for programmer laziness
That's precisely what you're doing when you use javac. It's outputting 'crap code' and relying on 'compiler magic' (the JIT compiler on platforms where it's available) to make up for programmer laziness (targetting a stack-based virtual machine, using a mediocre compiler, not explicitly optimzing everything by hand, using dynamic dispatch, ...).
Member since:2005-10-08
"2) That optimization violates software engineering principles, by performing (provably-correct) transformations that result in code streams you feel should only be provided given sufficient annotation."
You are putting words in my mouth, and over-generalizing my position in order to support your strawman argument. I did not contradict myself.
"All optimization boils down to catering to "lazy programming," where "lazy programming" means not hoisting responsibility for efficiency needlessly to the programmer."
I disagree. Often optimization boils down to "readable programming", not lazy programming.
"There is no "aversion" to "doing it the right way," doing it "the right way" is simply unnecessary."
And again, I am not fond of compiler tricks that encourage programmers to write sloppy code that violates good software engineering principles. There is a difference between good software engineering principles, and programmer laziness. Which is something it seems you cannot grasp.
"First, what you have presented is an opinion, not a fact."
Now I KNOW for sure you missed out on software enginnering 101. The principle of least privilege is one of the most fundamental aspects of good software engineering. If a variable will not be modified, it should be declared as such to prevent the programmer from accidently modidying it later. Let me guess. You are probably on of those programmers who routinely passes around pointers without declaring them to be const too right? Again, it violates principles of good software engineering, and is bad style. If the pointer will not be modified in the called function, it should be declared as const so it cannot be modified. This is not advanced stuff. This is software engineering 101. The final keyword is no different.
Member since:
2005-10-08
"Your argument boils down to "javac doesn't perform an optimization and therefore the optimization is bad, and I will stick to that regardless of how clearly it demonstrates that I've never written or worked on an optimizing compiler in my entire life.""
I HAVE written compilers. Have you?
An optimization that says "this arithmetic operation can be done faster if it is bitwise shifted" is one thing. This optimizes details that the programmer should not be bothered to worry about, and details that if the programmer did worry about, would decrease code readability.
In the case in question, however, you are basically asking the compiler to make up for lazy programming, and programming that is bad style. That is something I am not a fan of. Again, what is your aversion to doing it the right way?
int c = 5;
final int c = 5;
Are you just too lazy to type that extra word "final"?
"Such annotations guarantee absolutely no optimization. The optimization is simply easier for the less sophisticated optimizer to make because the programmer has explicitly performed its job for it while providing annotations for assisting the programmer to obtain correct code."
Wrong. In Java, this annotation does guarantee that code wrapped inside a conditional and based on the final variable will be removed by the compiler. And it also follows good software engineering prinicples (which is something you still haven't addressed. The fact that it is bad style from an engineering standpoint and decreases code readability, and it hardly anymore work to di it the right away. You need to type one extra word.)
If you want to write crap code that relies on compiler magic to make up for programmer laziness, be my guest. But don't plan on working for my company. Again, it's not like we are talking about substituting a bitwise shift for some other arithmetic operation here. In this case, we are talking about the compiler making up for excessively lazy programming.