Project Lambda: Java Language Specification draft

[Reinier Zwitserloot]

If there's some pragmatic use case that is considerably slower 'where it
counts' with the existing list literal proposal (list literals are immutable
and to create mutable ones or ones with non-standard behaviours, and you
still want to use list literals, you have to wrap the literal in e.g. "new
ArrayList<T>(_LITERAL_)") - that'd be interesting. However, ecj remains an
example that going by your gut does not lead to good results.

The foreach implementation could have been built differently, however, the
number of foreach loops that get rewritten just to avoid the second method
call are rather scarce, so, I don't see how this is proof that we should
_complicate_ new language proposals just to accomodate such micro
optimization concerns.

Now, if an alternate proposal for list literals exists that does cater to
these concerns and is also more elegant, or at least not more complicated,
that'd be worth considering, of course. Performance (at least at this level)
is not nearly as important as a clean API and a simple easy to understand
feature; that does not of course mean that performance is completely
irrelevant, either. It just plays second fiddle.

--Reinier Zwitserloot



On Thu, Jan 28, 2010 at 8:11 PM, Neal Gafter <neal at gafter.com> wrote:

> On Thu, Jan 28, 2010 at 10:55 AM, Reinier Zwitserloot
> <reinier at zwitserloot.com> wrote:
> >>  my NetBeans compiles pretty fast too, indeed both compilers are now
> >> I/O-constrained on any recent machine/JVM, so this is not anymore a good
> >> case study.
> >>
> >
> > So, javac vs. ecj is no longer a good case study? Huh? No, it _IS_ a good
> > case study, it is serious anecdotal avidence that that
> micro-optimization,
> > which is what ecj has done, does not help performance any, and instead
> makes
> > a dog of a code base that is such a drag on maintainability and
> flexiblity
> > that eclipse is legendary for lagging behind new java features so much.
>
> Reiner: have you actually looked at the javac code base?  It's got
> lots of micro-optimizations.  For the most part, they were done
> because the changes made a significant difference in compile-time.  I
> think the more likely explanation of the lag in language features is
> that Sun and others use javac (not ecj) to prototype new language
> features.
>
> By the way, looping through an ArrayList using indexing happens to be
> faster than looping through using an iterator because the latter
> requires two method calls per element, while the former requires only
> one.  It's not hard to verify this experimentally.  Had the for-each
> loop been library-defined, it could have been changed to a more
> efficient implementation in later releases.
>