Re: Groovy performance: what to do

> Hey Alex,
>
> Actually, I wanted to propose something similar before. I'm very happy
> you got this working!
>
> I think the annotation is great. Do you think there could also be a
> syntax that does the same, like:
>
> assert strict { 1 + 1 } == 2
>
> Thanks
>
> Steven
>
>
> On Feb 19, 2008 11:10 AM, Alex Tkachman <alex.tkachman@...> wrote:
> > 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
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>