Re: 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
>