G++ with Grails
Alex Tkachman
Latest version of Groovy++ (v 0.2.19) is based on Groovy
1.7.5-snapshot, which means it is fully compatible with Grails 1.3.4.
I even managed to write some tests and see noticeable (3-4 times)
performance gain. BTW, this is achieved in mixed mode (vs. strictly
statically typed) so all beauty of Grails dynamic methods are still in
place.
Here is what need to be done if you wish to run your our tests:
- download Groovy++ at http://code.google.com/p/groovypptest/downloads/list
- replace in your grails 1.3.4 installation file
/lib/groovy-all-1.7.4.jar with file /embeddable/groovypp-0.2.19.jar
from Groovy++
- replace in grails installation reference to groovy-all-1.7.4.jar in
file /bin/startGrails(.bat) by reference to groovypp-0.2.19.jar
- replace in grails installation reference to groovy-all-1.7.4.jar in
file /conf/groovy-starter.conf by reference to groovypp-0.2.19.jar
- annotate some classes or methods with @Typed(TypePolicy.MIXED)
Please report your success or problems at Groovy++ Google Group -
http://groups.google.com/group/groovyplusplus
Enjoy,
Alex
Alex Tkachman
which I can qualify for voting :)
Regarding writing static code with Java I disagree. Main point for me
to create G++ was to have language which would be convenient and
non-verbose. I write a lot last months on G++ and can tell that it is
huge productivity boost compare to plain Java. Performance here is one
of requirements but not main goal.
Microbenchmarking is never truth but almost always good indication of
general trend and ground for expectations.
On Sun, Aug 15, 2010 at 2:41 PM, Stephane Maldini <smal...@doc4web.com> wrote:
> Hi Alex,
> I will give a try ASAP, it seems promising. But here some thoughts ($0.02):
>
>
> Usual remark : Name is confusing, people could be tempted to believe Groovy
> vanilla does not fit their needs as Groovy++ - Vote for a new name sounds
> cool (as tried before if I remember correctly).
> Usual remark (bis) : Groovy beauty is about dynamic, Mixed Mode is cool and
> deserves attention but if I would want to write static code I will go for
> Java.
> In fact today, in my experience, Grails applications are just the front for
> underlying java libraries or some middlewares.
> Beating microbenchmarks is the Java work, even if Groovy 1.8 will be about
> performing this part aswell
> I will certainly try this cool stuff for some Http push applications (using
> ICEpush not cometD) as your results on this topic seem very promising.
>
> Cheers
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
>
>
> --
> Stéphane MALDINI
> doc4web consultant
> smal...@doc4web.com
> --
> http://fr.linkedin.com/in/smaldini
>
Alex Tkachman
service layer is great area for use of Groovy++ but it will be more
clear after more experienced people tried it.
On Sun, Aug 15, 2010 at 2:57 PM, Tomas Lin <toma...@gmail.com> wrote:
> This is quite exciting.
>
> Are there some guidelines to which areas in a grails application (
> i.e. domain objects, services, controllers, views, etc ) might benefit
> most from a g++ optimisation?
>
> Would it be possible to see an example of this, for example, having an
> annotated Petclinic application?
Alex Tkachman
use invokedynamic and I am not sure will ever use it. But similar call
site caching technic I implemented in 1.6 already gave Groovy serious
performance boost. I know that Jochen has very interesting ideas to
implement in 1.8 which also can improve performance of Groovy Core.
But I want to reiterate that performance is only one of topics in
agenda of Groovy++. Static compilation (compile time errors vs runtime
errors) is another extremely important one.
On Sun, Aug 15, 2010 at 3:18 PM, Sebastian Hohns <seb...@gmx.de> wrote:
>
> thank you for your work. Doesn't target this the same problems already solved
> with all this invokedynamic (was it JSR-292???) stuff coming with Java7? Do
> you expect (or did you already do some benchmarking) further significant
> performance improvements with G++ vs. a v7 JVM? I didn't do any research
> about this because we are very pleased with the current grails performance,
> but at the first glance it seems like there will be some overlapping between
> both.
> --
> View this message in context: http://grails.1312388.n4.nabble.com/G-with-Grails-tp2325786p2325881.html
> Sent from the Grails - user mailing list archive at Nabble.com.
Richard Vowles
---
Richard Vowles,
Grails, Groovy, Java
Consistency is the last refuge of the unimaginative - Oscar Wilde
ph: +64275467747, linkedin, skype:rvowles
get 2Gb shared disk space in the cloud - Dropbox, its incredibly useful! - http://tinyurl.com/cmcceh
podcast: http://www.illegalargument.com
slippytoad
did work was to copy groovypp-all-0.2.19.jar instead of
groovypp-0.2.19.jar to $GRAILS_HOME/lib and reference that jar in the
other two files.
Cheers,
Nick.
On Aug 15, 2:03 am, Alex Tkachman <alex.tkach...@gmail.com> wrote:
> Hi All!
>
> Latest version of Groovy++ (v 0.2.19) is based on Groovy
> 1.7.5-snapshot, which means it is fully compatible with Grails 1.3.4.
> I even managed to write some tests and see noticeable (3-4 times)
> performance gain. BTW, this is achieved in mixed mode (vs. strictly
> statically typed) so all beauty of Grails dynamic methods are still in
> place.
>
> Here is what need to be done if you wish to run your our tests:
Alex Tkachman
But now we have plugin
domiko
1 >
Nice work you're doing on G++.
It'll make Grails even more appealing
2 >
I've @Typed a service class I'm using as part of Grails app.
I've obviously had to refactor a bit but I get the following error msg
on compilation for which I have no solution:
a)
<code>
[groovyc] Compiling 2 source files to C:\Data\j\supafly\target\classes
[groovyc]
org.codehaus.groovy.control.MultipleCompilationErrorsException:
startup failed:
[groovyc] C:\Data\j\supafly\grails-app\services\supafly
\CoreService.groovy: 199: Internal Error:
java.lang.ArrayIndexOutOfBoundsException: -1
[groovyc] @ line 199, column 2.
[groovyc] User updateUser(params) {
[groovyc] ^
[groovyc]
[groovyc] 1 error
</code>
The params variable is the request parameters comming straight from
the controller.
I always thought that its type (of params) implemented the Map
interface, so I tried
<code>User updateUser(Map params) (tried with HashMap and
LinkedHashMap also)</code>
But that gives the same error.
b)
<code>
[groovyc] Compiling 2 source files to C:\Data\j\supafly\target
\classes
[groovyc]
org.codehaus.groovy.control.MultipleCompilationErrorsException:
startup failed:
[groovyc] C:\Data\j\supafly\grails-app\services\supafly
\DolomiteService.groovy: 59: Cannot modify final field
supafly.DolomiteService$createFormTemplate$2.title
[groovyc] @ line 59, column 5.
[groovyc] title = params[it]
[groovyc] ^
[groovyc]
[groovyc] 1 error
</code>
title is declared as a String
Thanks for your help.
Dominique
On Aug 15, 2:42 pm, Alex Tkachman <alex.tkach...@gmail.com> wrote:
> I am not Grails expert at all to give any guidelines. My guess is that
> service layer is great area for use of Groovy++ but it will be more
> clear after more experienced people tried it.
>
> > This is quite exciting.
>
> > Are there some guidelines to which areas in a grails application (
> > i.e. domain objects, services, controllers, views, etc ) might benefit
> > most from a g++ optimisation?
>
> > Would it be possible to see an example of this, for example, having an
> > annotated Petclinic application?
>
> >> Hi All!
>
> >> Latest version of Groovy++ (v 0.2.19) is based on Groovy
> >> 1.7.5-snapshot, which means it is fully compatible with Grails 1.3.4.
> >> I even managed to write some tests and see noticeable (3-4 times)
> >> performance gain. BTW, this is achieved in mixed mode (vs. strictly
> >> statically typed) so all beauty of Grails dynamic methods are still in
> >> place.
>
> >> Here is what need to be done if you wish to run your our tests:
Alex Tkachman
final (as in java inner classes) so you can not modify it.
With a) it seems to be bug in the compiler. I amafraid to fix it I
need minimal possible piece of code, which reproduce the problem. I
will do my best to fix asap.
.
domiko
about a)
Using 0.2.20 seems to get rid of the issue.
about b)
Good point.. :)
I'm trying to get more classes @Typed ...
but dynamic finders, dynamic methods (such as .hasErrors()) and
constraints section of domain classes are preventing further
optimization.
Any idea on how to deal with the dynamic nature of domain classes?
rgds,
Dominique
On Aug 20, 3:43 pm, Alex Tkachman <alex.tkach...@gmail.com> wrote:
> Regarding b) it is easy: in Groovy++shared variables in closures are
> final (as in java inner classes) so you can not modify it.
>
> With a) it seems to be bug in the compiler. I amafraid to fix it I
> need minimal possible piece of code, which reproduce the problem. I
> will do my best to fix asap.
> .
>
Alex Tkachman
What it does is interesting trick - compiler try to compile statically
as much as it can but for the rest use dynamic calls.
domiko
I forgot to put back the TypePolicy.MIXED (which should help
tremendously with dynamic finders :) ).
So the "java.lang.ArrayIndexOutOfBoundsException: -1 " problem is
still around..
I'll try to upload a dummy project to help reproduce
rgds,
Dominique
Alex Tkachman
debug grails-involved compilation
domiko
Mixed mode is a neat feature indeed.
On Aug 21, 10:13 pm, Alex Tkachman <alex.tkach...@gmail.com> wrote:
> Did you try @Typed(TypePolicy.MIXED)?
>
> What it does is interesting trick - compiler try to compile statically
> as much as it can but for the rest use dynamic calls.
>