Performance / memory leak?

[pkieltyka]

Hey guys,

I just recently started using therubyrhino as I'm trying to use JRuby more in production. I noticed that it's much slower then therubyracer (v8). I was wondering if there is something I can do to speed this up?

Also, I'm using this to compile handlebars.js templates via an API, and just for testing, I turned off all caching and hit the endpoint continually, after about 300 requests, I get lots of Java::JavaLang::OutOfMemoryError errors... any suggestions? I know I can tune the amount of Perm memory used by the Java process, however, I just wanted to make sure there isn't a memory leak or that I'm doing something wrong that throws off the GC.

Here is the method: https://gist.github.com/921174ac19790da21b42

Thx.

Peter

[kares]

Hey Peter, the slowness is caused by running Rhino mostly in interpreter (slowest) mode. ExecJS, less.rb (and maybe others as well) force Rhino's Context into this I think you've hit the 64k size issue as well (since you have a TODO there :)) - that's very unfortunate and already reported as #23 (as it makes therubyrhino seem pretty slow) there's even a pull on Rhino to address it.

As for the "potential" memory leak, I'm not sure we can help just by looking into a snippet, you should carefully examine your memory requirements e.g. start with a lower number of concurrent requests and make a load and see if memory blows off eventually after a few rounds (the JavaScript eval you're doing might just require a lot of memory - but it does not necessary mean a leak).

[mrbrdo]

Well even at 2.0.2, this gem is terribly slow compared to v8 (I mean, the difference is absolutely huge, it's seconds vs. minutes). I actually set up my deploy tasks to precompile using MRI with therubyracer on a lot of my projects, because I cannot stand waiting 5 minutes for a precompile that doesn't even do anything (assets already precompiled from previous deploy and it still takes ages).

Is there anything that can be done about this? Is it the Rhino engine really that is so slow, or is it this gem?

[kares]

it's that (very) slow probably due ExecJS forcing rhino into interpreted mode ... unfortunately a change to not do that was not accepted https://github.com/sstephenson/execjs/pull/112 I'm not sure why it simply got closed after long silence.

@mrbrdo it's probably best if you do it with MRI ... until - there might be some better (gem) options coming in for JRuby

Rhino itself served us for long and now it's getting retired as DynJS and others emerge ... closing this since there's nothing we can do on our part related to the leak/performance issue.

[mrbrdo]

Is it not feasible to create a fork of execjs that could be used with rhino until there is a viable alternative like DynJS?

[kares]

well the PR had to come from somewhere :) https://gist.github.com/kares/4329513

[mrbrdo]

Thanks, I'll give it a go. PS: Since you mentioned DynJS.. Are you aware of anyone making a wrapper?

[kares]

@mrbrdo do not expect too much (~ 30% if any) ... the TorqueBox guy(s) were trying something out a while back.