seanjensengrey / kiama

Automatically exported from code.google.com/p/kiama
GNU Lesser General Public License v3.0
0 stars 0 forks source link

Do a basic performance analysis #30

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Just try to see if there are any obvious bottlenecks on the example code. Can 
we use something like 
VisualVM?

Original issue reported on code.google.com by inkytonik on 5 Nov 2009 at 5:24

GoogleCodeExporter commented 9 years ago

Original comment by inkytonik on 10 Nov 2009 at 5:11

GoogleCodeExporter commented 9 years ago
Profiling Scala code is not easy at the moment.  After trying VisualVM with no 
success (errors instrumenting code and very slow it seems) I 
managed to get some profiles from NetBeans.  Profiling doesn't seem to be 
in-built for Scala projects yet but we can do it by attaching to a 
separate Scala program, but it's a bit fiddly.

Use Profile|Attach Profiler then specify Local and Direct as the attach mode.  
Hit Next a couple of times.  This will give you a JAVA_OPT that 
needs to be specified when running the program.  Use this style:

JAVA_OPTS="STUFF THAT NETBEANS GIVES YOU" scala -cp <whatever> <main class> 
<args>

Since this is so fiddly, I only tried one program which is non-trivial but 
still fairly small, our teaching Obr compiler. On CPU the class loader 
was by far the biggest user and on memory string usage seemed to be the 
highest.  In Kiama code, the parser memoisation entries were the 
most memory hogging, but not much compared to the overall usage.  None of the 
Obr compiler code itself made any impact on the profiles 
really.

In the future when better tools are available and larger Kiama examples are 
around, we should do a more detailed look at performance of the 
library, particularly the rewriting which is not used by the Obr compiler.

Original comment by inkytonik on 11 Nov 2009 at 5:42