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: obe...@tirant.com <mailto:cor...@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 <blackd...@gmx.org> wrote: > > > > On 29.03.2017 10:19, Paul Moore wrote: >> On 28 March 2017 at 22:08, Nelson, Erick <erick.nel...@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
