[prev in list] [next in list] [prev in thread] [next in thread] 

List:       groovy-user
Subject:    Re: [groovy-user] Re: CompileStatic & Static Fields
From:       Jochen Theodorou <blackdrag () gmx ! org>
Date:       2014-08-22 15:18:12
Message-ID: 53F75F34.2000801 () gmx ! org
[Download RAW message or body]

Am 22.08.2014 16:06, schrieb Keegan Witt:
[...]
> Is it still more expensive to use explicit types
> instead of def?  Any ballpark estimates on how much more?  Do
> @CompileStatic or @TypeChecked change that at all?

The reason using explicit types are worse is that a lot of Groovy style 
casting may happen. for example in T t; t = foo(), since we don't know 
the result of foo(), we will have to cast the result to T.

So for Groovy before 1.8 it is easy to say that using explicit types can 
slow down your program. In 1.8 I introduced primitive optimizations, so 
at least for primitives, it can be a gain to use the type. Now since I 
think Groovy 2.3 I tried to slim down the casting code a bit, hopefully 
reducing the amount of time spend there in many cases. But the general 
case is still not so good. I also changed the indy variant in this 
version, so that casts go through indy now. Instead of using the naive 
conversion method before, I can now actually see what type is provided 
and in the best case just return the object and have that cached (the 
naive way is uncached, but does not use a dynamic method call either). 
So at least since 2.3 casts in the indy version should not have a 
significant slowdown anymore.

Then @TypeChecked, there is no change compared to dynamic Groovy, since 
@TypeChecked does not do any changes to the compiler output. But in 
@CompileStatic it should be like in Java.

As for the amount of slowdown... difficult to estimate. As with Java's 
boxing, there are cheap and not so cheap operations when you make a 
cast. Assuming we are not talking about primitives here and that in all 
cases the object to be cast is an instance of the target type...

You could maybe say that an indy version will be about double as fast as 
a Groovy untyped version and the Groovy typed version may 40% slower 
than the untyped one, but @CompileStatic should be faster in all cases. 
I made some benchmarks, but in the end they all don't count for two 
reasons:
* they are microbenchmarks, and as such have nothing to do with a real 
world application
* you cannot test a cast alone properly

and for indy as well as for @CompileStatic:
* they have different performance characteristics than normal Groovy, 
and as such do not compare easily to normal Groovy

So for example for those two having or not having types should not make 
a difference, while for normal Groovy it is a difference.

bye blackdrag

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


[prev in list] [next in list] [prev in thread] [next in thread]