Groovy performance: what to do

Hi Groovy Developers!

As many of you know I spent almost last 8 months (since July) working
mostly on different aspects of Groovy performance. And results so far
are very good - each new version are noticeably faster then previous
one.

But you know what - I feel myself like an idiot.

The problem we try to solve can be formulated very simply
- we have piece of code, which is effectlvely statically typed (either
typed already or can become typed without to much problems for
developer because he knows that nothing dynamic is involved)
- we forget almost all we know about types during compilation because
we assume that everything can be dynamicly changed at any momemt
- we try to achieve same performance as Java has by doing amounts of
very complicated tricks on runtime

After 4th attempt to rewrite call sites optimization and avoid some
very tricky bugs with EMC and categories on multi-threading I felt
that it is not the best way to spend my life.

At this point I remind myself well-known rule that 95% of performance
problems come from 5% of code. Well, we can argue about exact figures
- some people say 99-1, some 90-10, some 80-20 and I my personal
experience during many years is 95-5 but I don't think it is really
matter.

What is really matter is that instead of runtime optimizing everything
without help of developer I (as developer) would prefer to help
compiler to optimize 5% of code, which is performance critical for me.

So I did simple experiment
- I introduced annotation

@Retention(RetentionPolicy.SOURCE)
@Target({ElementType.TYPE,ElementType.METHOD,ElementType.CONSTRUCTOR})
public @interface Typed {
    public enum TypePolicy {
         Dynamicly,    // traditional Groovy, no resolve
         Strictly,           // traditional Java, full resolve required
         SemiStrictly   // resolve and call statically what you can
and call the rest dynamically
   }

    TypePolicy value () default TypePolicy.Strictly;
}

- I prototyped compiler modification to use for static resolve (for
Strictly and SemiStrictly) both type information, DGM methods and
categories in use
- I prototyped work with primitives for  Strictly and SemiStrictly

- I experimented with just one script spectralnorm, which is my huge
headache last weeks and which is much much slower then Java
counterpart.

- By annotating just one method with @Typed it becomes only twice
slower compare to Java

- By annotating two methods it becomes only 5% slower than Java

Is it surprise? Of course, not.

Does it show right way to go? I believe so. Instead of fighting for
optimization of code, which is assumed to be dynamic (read can't be
really optimized) we give tool for developer to choose when he want to
optimize.

Someone can argue that developer can always use Java, when he needs
piece of statically typed code. There are several reasons why this is
wrong
- we seriously limit his freedom to develop
- if he needs just 1 or 2 statically typed methods, why to add another
Java class

Now when Groovy becomes more and more popular and used together with
tons of existing Java code we hear a lot of complains from users and
developers (like recent messages from Peter and Graeme) regarding need
for compile time (and even IDE level) type check instead od runtime.
The beuty of my approach is it also gives ability to mark  piece of
code as type checked.

I believe if we choose to implement this program Groovy will become
even stronger and appealing for Java developers.

What do you think?

Best regards
Alex

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email