Comments on: Groovy performance speed http://tiago.org/cc/2008/03/21/groovy-performance-speed/ Software engineering in a computational biology environment Sat, 05 Jul 2008 10:56:11 +0000 http://wordpress.org/?v=2.5.1 By: Free Articles http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-137 Free Articles Sat, 07 Jun 2008 04:00:03 +0000 http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-137 Articles are always search to hard but here are some options. http://www.eshariq.com Articles are always search to hard but here are some options.
http://www.eshariq.com

]]> By: tiago http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-9 tiago Sun, 23 Mar 2008 19:08:06 +0000 http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-9 An update to this, where I dissect part of the problem and suggest how to improve things can be found <a href="http://tiago.org/cc/2008/03/23/revisiting-groovy-performance-issues/" rel="nofollow">here</a>. An update to this, where I dissect part of the problem and suggest how to improve things can be found here.

]]> By: Cognitive Consonance » Blog Archive » Revisiting Groovy performance issues http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-8 Cognitive Consonance » Blog Archive » Revisiting Groovy performance issues Sun, 23 Mar 2008 19:04:49 +0000 http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-8 [...] tried to drill down the Groovy performance issue that I had with what is in practice a text processing [...] [...] tried to drill down the Groovy performance issue that I had with what is in practice a text processing [...]

]]> By: movk http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-7 movk Sun, 23 Mar 2008 13:45:38 +0000 http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-7 Groovy is great language. I thought it would be great to use it as application specific scripting language (Java application + user can add/extend functionality through Groovy scripts). Unfortunately, if such application is math oriented and larger amount of data is processed or complicated math used (scientific, business), then Groovy cannot be used because of performance (Scala may be the solution).I find Groovy great for building application skeleton and write performance critical part in JAVA. Groovy is great language. I thought it would be great to use it as application specific scripting language (Java application + user can add/extend functionality through Groovy scripts). Unfortunately, if such application is math oriented and larger amount of data is processed or complicated math used (scientific, business), then Groovy cannot be used because of performance (Scala may be the solution).I find Groovy great for building application skeleton and write performance critical part in JAVA.

]]> By: tiago http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-6 tiago Sun, 23 Mar 2008 12:08:09 +0000 http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-6 The code could be better, that is for sure. And I will revisit this shortly. I have lots of stuff going and sometimes things get rushed out. I actually hate duck typing (which I used out of lazyness and being in a hurry) There is one point though: Considering that Groovy is a language that puts itself as the "next easier step" after Java, it should allow for better results than this when using Groovy in a Java idiomatic way. This is not an excuse for the poor quality of the code, just a realistic comment for a language that is positioned the way Groovy is. The code could be better, that is for sure. And I will revisit this shortly. I have lots of stuff going and sometimes things get rushed out. I actually hate duck typing (which I used out of lazyness and being in a hurry)

There is one point though: Considering that Groovy is a language that puts itself as the “next easier step” after Java, it should allow for better results than this when using Groovy in a Java idiomatic way. This is not an excuse for the poor quality of the code, just a realistic comment for a language that is positioned the way Groovy is.

]]> By: Sakuraba http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-5 Sakuraba Sun, 23 Mar 2008 10:23:13 +0000 http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-5 The "def" is more like "Object". I dont think that explicitely typing it makes a difference. I think you found some kind of hotspot there. The speed difference is definetly not normal. I just dont understand why you did not try to make to make it more idiomatic Groovy. Your code is very hard to read. The “def” is more like “Object”. I dont think that explicitely typing it makes a difference.

I think you found some kind of hotspot there. The speed difference is definetly not normal.

I just dont understand why you did not try to make to make it more idiomatic Groovy. Your code is very hard to read.

]]> By: Dooby http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-4 Dooby Sun, 23 Mar 2008 00:25:46 +0000 http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-4 It is quite bad that you say something exhibits poor performance, yet the code shows you have little to zero knowledge of the thing you are writing the code in... Seriously, just changing a type to the word "def" does not make something Groovy... You've just given yourself all the speed losses of being interpreted, with none of the gains of the Groovy language It is quite bad that you say something exhibits poor performance, yet the code shows you have little to zero knowledge of the thing you are writing the code in…

Seriously, just changing a type to the word “def” does not make something Groovy… You’ve just given yourself all the speed losses of being interpreted, with none of the gains of the Groovy language

]]> By: Ted Naleid http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-3 Ted Naleid Sun, 23 Mar 2008 00:02:25 +0000 http://tiago.org/cc/2008/03/21/groovy-performance-speed/#comment-3 I would have expected a performance hit in groovy over java, but that does seem like a large one. Are you using the latest version of groovy (1.5.4)? I'm also wondering if the groovy code would be any faster if it leveraged some useful groovy constructs rather than being a mostly straight copy of the java code. Something like: def colIndivSize = colIndiv.size() + 11 reader.eachLine { line -> lineTok = line.tokenize() if (lineTok.size() == colIndivSize) { indivs.eachWithIndex { iIndiv, i -> def iCase = lineTok[indivPos[iIndiv]] if (iCase.equals('NN')) continue indivs[i..-1].eachWithIndex { jIndiv -> def jCase = lineTok[indivPos[jIndiv]] if (jCase.equals('NN')) continue if (jCase - iCase != jCase) counts[iIndiv + jIndiv] += 1 } } } } (I think this is a direct port of what you have, but I don't have your full source or a test file so I might have missed something) I would have expected a performance hit in groovy over java, but that does seem like a large one. Are you using the latest version of groovy (1.5.4)?

I’m also wondering if the groovy code would be any faster if it leveraged some useful groovy constructs rather than being a mostly straight copy of the java code.

Something like:

def colIndivSize = colIndiv.size() + 11
reader.eachLine { line ->
lineTok = line.tokenize()
if (lineTok.size() == colIndivSize) {
indivs.eachWithIndex { iIndiv, i ->
def iCase = lineTok[indivPos[iIndiv]]
if (iCase.equals(’NN’)) continue
indivs[i..-1].eachWithIndex { jIndiv ->
def jCase = lineTok[indivPos[jIndiv]]
if (jCase.equals(’NN’)) continue
if (jCase - iCase != jCase) counts[iIndiv + jIndiv] += 1
}
}
}
}

(I think this is a direct port of what you have, but I don’t have your full source or a test file so I might have missed something)

]]>