groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From obesga <obe...@tirant.com>
Subject Re: Optimising a Groovy script
Date Wed, 29 Mar 2017 20:08:10 GMT
If you use a compiled code - not an interpreted script

- Use Java 8 and the indy libraries and compiler
- Use the @CompileStatic annotation on your code, or on some of it. But you could lose some
of the advantages of the dynamic code

http://stackoverflow.com/questions/14762094/should-i-use-groovys-compilestatic-if-im-also-using-java-7
<http://stackoverflow.com/questions/14762094/should-i-use-groovys-compilestatic-if-im-also-using-java-7>

Hope it helps


	
	
Oscar Besga Arcauz
Editorial Tirant lo Blanch
C/ Artes Gráficas, 14, entlo.
46010 - Valencia
Telf. 963 610 048
Correo electrónico: obesga@tirant.com <mailto:correo@tirant.com>
Editorial <http://www.tirant.com/> • Librería Tirant <http://www.tirant.es/>
• Librería Juridica <http://www.tirantderecho.com/> • Tirant Humanidades <http://www.tirant.com/humanidades>
• Tirant México <http://www.tirant.com/mex> • Corporativa  <http://www.tirant.net/>•
Tirant Online <http://www.tirantonline.com/> • Tirant Formación <http://www.tirantformacion.com/>
•Tirant Asesores  <http://www.tirantasesores.com/>• Tirant Notarios <http://notariado.tirant.com/>
• Tirant DDHH <http://derechoshumanos.tirant.com/> • Tirant Online México <http://www.tirantonline.com.mx/>
• Tirant Latam <http://latam.tirantonline.com/latam/> • Tirant Propiedad Horizontal
<http://propiedadhorizontal.tirant.com/> • Biblioteca Virtual <http://biblioteca.tirant.com/>
•Nube de Lectura <http://www.nubedelectura.com/>
ADVERTENCIA LEGAL:

De conformidad con lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, de Protección
de Datos de Carácter Personal y en la Ley 34/2002, de 11 de julio, de Servicios de la Sociedad
de la Información y de Comercio Electrónico, le comunicamos que los datos de carácter personal
utilizados en este envío están incluidos en el fichero "CLIENTES-PROVEEDORES” cuya titularidad
ostenta EDITORIAL TIRANT LO BLANCH S.L. puede ejercer sus derechos de acceso, rectificación,
cancelación y oposición mediante comunicación escrita a CALLE ARTES GRAFICAS, Nº 14 BAJO,
46010, VALENCIA en la dirección indicada o en el correo electrónico remitente. 

Le notificamos que este mensaje va dirigido exclusivamente a la persona designada como destinatario
y que la información que contiene es confidencial. Si Vd. ha recibido este mensaje por error
le rogamos nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda
a su eliminación así como a la de cualquier documento adjunto al mismo, quedando prohibida
cualquier divulgación, distribución o copia del mismo. 

El consumo de papel es perjudicial para el medio ambiente. Por favor téngalo en cuenta antes
de imprimir este mensaje.

> On 29 Mar 2017, at 17:46, Jochen Theodorou <blackdrag@gmx.org> wrote:
> 
> 
> 
> On 29.03.2017 10:19, Paul Moore wrote:
>> On 28 March 2017 at 22:08, Nelson, Erick <Erick.Nelson@hdsupply.com> wrote:
>>> Try this...
>> 
>> Thanks for the suggestion - there were some nice improvements in here.
>> 
>>> def rng = new MersenneTwister()
>>> 
>>> def roll = {
>>>        rng.nextInt(6) + rng.nextInt(6) + rng.nextInt(6) + 3
>>> }
>> 
>> You changed my definitions to use "def" here. This seems to be the
>> thing that makes the most difference in performance. I'm really
>> struggling to find a good explanation as to the effect of using or not
>> using "def".
> 
> 
> basically it depends on if Groovy thinks there has to be a cast here or not and if the
primitive optimizations can kick in.
> 
>> I had imagined that using "int roll() {..." would be
>> better, as it explicitly states the types which would help the
>> compiler avoid the need for generic code. Obviously I was wrong, but
>> I'm not at all clear why.
> 
> yes, it is better, but only if primitive optimizations are working... or if you compile
static. I haven't looked into why, but in
> 
>>        int n = roll()
>>        results[n] = results.containsKey(n) ? results[n] + 1 : 1
> 
> result is referenced outside the closure and I think that is already enough to not have
primitive optimizations in use here. Which means you have to pay the boxing cost from int
to Integer and back to int for every call to roll... and then you have again boxing for results.containsKey(n)
and results[n]= and results[n] + 1. In that case it looks really much better to just use Integer
from the start, thus def has an advantage here.
> 
>> Also, if I use "def rng" but keep "int roll()", I get an error "No
>> such property: rng". I'm not clear why that is.
> 
> you wrote a script, not a class, thus
> 
> rng = new MersenneTwister()
> 
> will set a variable called rng in the binding, and
> 
> int roll() {
>    rng.nextInt(6) + rng.nextInt(6) + rng.nextInt(6) + 3
> }
> 
> this will use rng from the binding.
> 
> def rng = new MersenneTwister()
> 
> will make a local variable and leaves the binding rng blank, thus roll gets into trouble
> 
>> Do you know of a good resource that explains the difference between
>> using def and not doing so?
> 
> hm... I think the page I wrote back then got lost in the codehaus move :(
> bye Jochen


Mime
View raw message