

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
62 messages in org.codehaus.groovy.devRe: [groovy-dev] Groovy performance: ...| From | Sent On | Attachments |
|---|---|---|
| Alex Tkachman | Feb 19, 2008 2:09 am | |
| Steven Devijver | Feb 19, 2008 2:37 am | |
| Alexandru Popescu ☀ | Feb 19, 2008 2:57 am | |
| Alex Tkachman | Feb 19, 2008 3:03 am | |
| Patric Bechtel | Feb 19, 2008 3:12 am | |
| Guillaume Laforge | Feb 19, 2008 3:25 am | |
| Guillaume Laforge | Feb 19, 2008 3:26 am | |
| Patric Bechtel | Feb 19, 2008 5:05 am | |
| Gavin Grover | Feb 19, 2008 5:51 am | |
| Steven Devijver | Feb 19, 2008 5:52 am | |
| Guillaume Laforge | Feb 19, 2008 5:54 am | |
| Tom Nichols | Feb 19, 2008 6:26 am | |
| Alex Tkachman | Feb 19, 2008 6:28 am | |
| Guillaume Laforge | Feb 19, 2008 6:35 am | |
| Tom Nichols | Feb 19, 2008 7:03 am | |
| Guillaume Laforge | Feb 19, 2008 7:38 am | |
| Chanwit Kaewkasi | Feb 19, 2008 7:52 am | |
| Charles Oliver Nutter | Feb 19, 2008 8:49 am | |
| Steven Devijver | Feb 19, 2008 10:03 am | |
| Charles Oliver Nutter | Feb 19, 2008 11:38 am | |
| Steven Devijver | Feb 19, 2008 12:11 pm | |
| Alex Tkachman | Feb 19, 2008 12:39 pm | |
| Alex Tkachman | Feb 19, 2008 12:48 pm | |
| tugwilson | Feb 19, 2008 1:36 pm | |
| Alex Tkachman | Feb 19, 2008 8:51 pm | |
| Guillaume Laforge | Feb 20, 2008 2:10 am | |
| Jochen Theodorou | Feb 20, 2008 9:46 am | |
| Martin C. Martin | Feb 20, 2008 5:25 pm | |
| Guillaume Laforge | Feb 21, 2008 1:35 am | |
| Tom Nichols | Feb 21, 2008 4:15 am | |
| Martin C. Martin | Feb 21, 2008 5:44 am | |
| Tom Nichols | Feb 21, 2008 6:22 am | |
| Smith, Jason, CTR, OASD(HA)/TMA | Feb 21, 2008 6:34 am | |
| Martin C. Martin | Feb 21, 2008 6:43 am | |
| Guillaume Laforge | Feb 21, 2008 6:48 am | |
| Guillaume Laforge | Feb 21, 2008 7:04 am | |
| Smith, Jason, CTR, OASD(HA)/TMA | Feb 21, 2008 7:18 am | |
| Charles Oliver Nutter | Feb 21, 2008 7:38 am | |
| Guillaume Laforge | Feb 21, 2008 7:42 am | |
| Martin C. Martin | Feb 21, 2008 8:36 am | |
| Martin C. Martin | Feb 21, 2008 8:48 am | |
| Pascal DeMilly | Feb 21, 2008 5:35 pm | |
| Gavin Grover | Feb 21, 2008 6:21 pm | |
| Jochen Theodorou | Feb 22, 2008 4:31 am | |
| Tom Nichols | Feb 22, 2008 4:49 am | |
| Charles Oliver Nutter | Feb 22, 2008 11:43 pm | |
| Guillaume Laforge | Feb 23, 2008 12:28 am | |
| Martin C. Martin | Feb 23, 2008 3:51 am | |
| Jochen Theodorou | Feb 23, 2008 2:49 pm | |
| Jochen Theodorou | Feb 23, 2008 2:53 pm | |
| Charles Oliver Nutter | Feb 24, 2008 2:01 am | |
| Martin C. Martin | Feb 24, 2008 3:56 am | |
| Martin C. Martin | Feb 24, 2008 4:11 am | |
| Charles Oliver Nutter | Feb 24, 2008 5:12 am | |
| Jochen Theodorou | Feb 24, 2008 3:17 pm | |
| Jochen Theodorou | Feb 24, 2008 3:31 pm | |
| Alexandru Popescu ☀ | Feb 24, 2008 3:36 pm | |
| Martin C. Martin | Feb 26, 2008 2:20 pm | |
| Martin C. Martin | Feb 26, 2008 3:15 pm | |
| Jochen Theodorou | Feb 27, 2008 2:38 am | |
| Jochen Theodorou | Feb 27, 2008 3:03 am | |
| Martin C. Martin | Mar 2, 2008 5:21 pm |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [groovy-dev] Groovy performance: what to do | Actions... |
|---|---|---|
| From: | Guillaume Laforge (glaf...@gmail.com) | |
| Date: | Feb 19, 2008 3:25:13 am | |
| List: | org.codehaus.groovy.dev | |
This is an interesting experiment.
You've done a great work so far on improving the performance of Groovy, and Groovy 1.6 will bring Groovy ahead of the pack as the most performant dynamic language for the JVM.
Congratulations for this work.
However, as this has been discussed on this list a few times already or at the last Groovy Developer Conference, it's better and saner to make Groovy the fastest dynamic language possible on the JVM by creating the best second generation MOP, rather than by adding a few hacks to make Groovy a more statically typed language.
What would happen if such a proposal was committed? In a few months from now, all Groovy code samples we would come across would be littered with @Typed annotations all around -- who remembers the ugly @Property annotation making your Groovy beans ugly? A few months later, and people will wonder why this is not the default behavior and be applied to all possible methods or classes. Groovy will become more and more statically typed, and for "performance sake", we'd imagine other such hacks to make Groovy less and less dynamic over time, or littered with ugly annotations.
Such a proposal would be a consent that we failed to make Groovy the fastest dynamic language possible. Have we really tried to make Groovy as fast as possible? Have we implemented a second generation MOP yet? No.
Furthermore, even with such an annotation, this code path would always be slower than raw Java anyway.
Remember that Groovy has not been conceived to replace Java, but as a complement, an adjunct, an enhancer to Java. It's a core value of the language and the project. With the joint compiler, the ant tasks, the maven plugin, it's so easy to just implement one additional Java class, that it is totally seamless and transparent to mix Groovy and Java together.
When raw performance matter, using Java is simply the best option, and nothing we could do would make the code faster than raw Java.
It doesn't mean that Groovy can't be made more performant than it is today, on the contrary, it's time to work on MOP2 instead. So you can focus your energy on something less frustrating if you so wish.
As discussed several times already, we should focus now on this new Meta-Object Protocol, perhaps to make Groovy even more dynamic, but to make it the faster possible dynamic language across all possible platforms -- it's not an unrealistic goal to be faster than Ruby and Python.
John Wilson and his experiments prove that even without call site caching and similar techniques, we can be even more performant than we are today with all these techniques applied. The Jython and JRuby guys, as well as the guys on the JVM language list prove us that there are better ways too.
If ever we recognize that this new architecture is a failure, we don't even need to implement such annotation trick, as the simplest possible way to make the code as performant as possible is to just implement a few lines of Java code to make the overal performance right so that all possible projects meet the expected stricter SLAs.
So, thanks a lot for this suggestion and experiment, but I think it's not the right direction to take in terms of performance improvements, but rather it's time we spend our time and energy on designing the next generation dynamic system for Groovy.
On Tue, Feb 19, 2008 at 11:10 AM, Alex Tkachman <alex...@gmail.com> 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:
-- Guillaume Laforge Groovy Project Manager G2One, Inc. Vice-President Technology http://www.g2one.com
--------------------------------------------------------------------- To unsubscribe from this list, please visit:







