Project Lambda: Java Language Specification draft

[Reinier Zwitserloot]

inline.

On Mon, Jan 25, 2010 at 2:13 PM, Osvaldo Doederlein <opinali at gmail.com>wrote:

These *gratuitous* inefficiencies always find a way to bite you in the butt.
>

Ridiculous hyperbole. The only performance issues I've ever run into were
solved by making much higher level optimizations, such as improving the
performance of a tight loop someplace. In fact, I have never run into a
situation where performance got nickel-and-dimed to death, nor have I met
anybody where this is the case. I'm not denying that it could _ever_ happen,
but you are literally saying that nickel-and-dime performance issues
*ALWAYS* occur, where in fact its more likely to be a 1 in 50,000 programs
occurrence.


> The result is often a balkanization of the language, as
> performance-critical code avoids some/all higher-level features.
>


The fact that some stupid tools write crappy micro-optimized code is not
proof that micro-optimization is a good idea or has any measurable effect.
Case in point: The code for ecj is a complete and utter dog - an
unmaintainable trainwreck. It's littered with use of char arrays instead of
strings, and they even mix generated code with handwritten code in a single
source file just to serve the micro-optimization god. javac on the other
hand, is almost laughably non-micro-optimized. They even use a conslist
(immutable lists defined as having a head element along with a tail list
containing all other elements. Appending something to the end of such a
thing costs a hefty O(n), needing to make a new object for each element in
the entire list) - which is not something hotspot optimizes well.

And yet, javac is doing about as well as ecj, speed-wise. Netbeans even uses
javac, with no speedups in the parser code, as-you-type. So, I pass the onus
of proof back to you, Osvaldo. I hereby claim that micro-optimizations
aren't worth it until proven otherwise.

See, I'm NOT proposing to twist the language design around such things
>

and yet in the next paragraph you propose considerably complicating the code
generated by the foreach loop depending on the compile-time type of the
iterable expression. This would introduce a bunch of new puzzlers and
potential for stuff to break when folks update to new libraries. In order
words, you *ARE* proposing to twist the language deisgn around such things.


> I'm still waiting for a justification.
>

Well, now you know why. There's also the issue of
ConcurrentModificationException which is much, much more difficult to track
when there isn't an Iterator object involved, if you needed another reason.
Trying to accomodate your micro-optimizations here would have complicated
everything.


> And don't come with cheap talking of "may be eliminated by hotspot" (EA /
> scalar replacement).
>

generational garbage collection and hotspot isn't cheap talk. Just compare
java 1.0 with java 1.6.


> You see, Java is not Groovy or Scala or Ruby or Clojure or even JavaFX
> Script.
>

How are these pacifisms helping the discussion forward? No, of course not.
What's your point?

 --Reinier Zwitserloot