62 messages in org.codehaus.groovy.dev[groovy-dev] Groovy performance: what...| From | Sent On | Attachments |
|---|---|---|
| Alex Tkachman | 19 Feb 2008 02:09 | |
| Steven Devijver | 19 Feb 2008 02:37 | |
| Alexandru Popescu ☀ | 19 Feb 2008 02:57 | |
| Alex Tkachman | 19 Feb 2008 03:03 | |
| Patric Bechtel | 19 Feb 2008 03:12 | |
| Guillaume Laforge | 19 Feb 2008 03:25 | |
| Guillaume Laforge | 19 Feb 2008 03:26 | |
| Patric Bechtel | 19 Feb 2008 05:05 | |
| Gavin Grover | 19 Feb 2008 05:51 | |
| Steven Devijver | 19 Feb 2008 05:52 | |
| Guillaume Laforge | 19 Feb 2008 05:54 | |
| Tom Nichols | 19 Feb 2008 06:26 | |
| Alex Tkachman | 19 Feb 2008 06:28 | |
| Guillaume Laforge | 19 Feb 2008 06:35 | |
| Tom Nichols | 19 Feb 2008 07:03 | |
| Guillaume Laforge | 19 Feb 2008 07:38 | |
| Chanwit Kaewkasi | 19 Feb 2008 07:52 | |
| Charles Oliver Nutter | 19 Feb 2008 08:49 | |
| Steven Devijver | 19 Feb 2008 10:03 | |
| Charles Oliver Nutter | 19 Feb 2008 11:38 | |
| Steven Devijver | 19 Feb 2008 12:11 | |
| Alex Tkachman | 19 Feb 2008 12:39 | |
| Alex Tkachman | 19 Feb 2008 12:48 | |
| tugwilson | 19 Feb 2008 13:36 | |
| Alex Tkachman | 19 Feb 2008 20:51 | |
| Guillaume Laforge | 20 Feb 2008 02:10 | |
| Jochen Theodorou | 20 Feb 2008 09:46 | |
| Martin C. Martin | 20 Feb 2008 17:25 | |
| Guillaume Laforge | 21 Feb 2008 01:35 | |
| Tom Nichols | 21 Feb 2008 04:15 | |
| Martin C. Martin | 21 Feb 2008 05:44 | |
| Tom Nichols | 21 Feb 2008 06:22 | |
| Smith, Jason, CTR, OASD(HA)/TMA | 21 Feb 2008 06:34 | |
| Martin C. Martin | 21 Feb 2008 06:43 | |
| Guillaume Laforge | 21 Feb 2008 06:48 | |
| Guillaume Laforge | 21 Feb 2008 07:04 | |
| Smith, Jason, CTR, OASD(HA)/TMA | 21 Feb 2008 07:18 | |
| Charles Oliver Nutter | 21 Feb 2008 07:38 | |
| Guillaume Laforge | 21 Feb 2008 07:42 | |
| Martin C. Martin | 21 Feb 2008 08:36 | |
| Martin C. Martin | 21 Feb 2008 08:48 | |
| Pascal DeMilly | 21 Feb 2008 17:35 | |
| Gavin Grover | 21 Feb 2008 18:21 | |
| Jochen Theodorou | 22 Feb 2008 04:31 | |
| Tom Nichols | 22 Feb 2008 04:49 | |
| Charles Oliver Nutter | 22 Feb 2008 23:43 | |
| Guillaume Laforge | 23 Feb 2008 00:28 | |
| Martin C. Martin | 23 Feb 2008 03:51 | |
| Jochen Theodorou | 23 Feb 2008 14:49 | |
| Jochen Theodorou | 23 Feb 2008 14:53 | |
| Charles Oliver Nutter | 24 Feb 2008 02:01 | |
| Martin C. Martin | 24 Feb 2008 03:56 | |
| Martin C. Martin | 24 Feb 2008 04:11 | |
| Charles Oliver Nutter | 24 Feb 2008 05:12 | |
| Jochen Theodorou | 24 Feb 2008 15:17 | |
| Jochen Theodorou | 24 Feb 2008 15:31 | |
| Alexandru Popescu ☀ | 24 Feb 2008 15:36 | |
| Martin C. Martin | 26 Feb 2008 14:20 | |
| Martin C. Martin | 26 Feb 2008 15:15 | |
| Jochen Theodorou | 27 Feb 2008 02:38 | |
| Jochen Theodorou | 27 Feb 2008 03:03 | |
| Martin C. Martin | 02 Mar 2008 17:21 |
| Subject: | [groovy-dev] Groovy performance: what to do![]() |
|---|---|
| From: | Alex Tkachman (alex...@gmail.com) |
| Date: | 02/19/2008 02:09:56 AM |
| List: | org.codehaus.groovy.dev |
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:




