Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Evaluate Rhino optimization levels #23

Closed
headius opened this Issue · 4 comments

2 participants

@headius

There have been numerous reports of therubyrhino being too slow to use in day-to-day development, specifically when precompiling assets. I wonder if it is because Rhino is not configure to optimize code?

http://www.mozilla.org/rhino/opt.html

I do not see anything in therubyrhino codebase that would alter whatever Rhino has as its default, so it is possible that it is only running in interpreted mode. Interpreted mode would almost certainly be much slower to execute.

This bug is to evaluate the available optimization modes and determine whether therubyrhino should set a higher optimization level by default than whatever Rhino has as its default. This may alleviate problems users are having with Rhino-based asset compilation running too slowly for normal use.

@kares
Collaborator

Thanks Charlie, would be great if such users reported our way as well esp. if they had a sample rails app so we can compare the compilation under MRI with V8 and JRuby + Rhino (and to know what were they compiling less files / coffeescript). I remember at some point having optimizations off cause it was not usable as it was constantly hitting the JVM limits (if I recall correctly it was the 64k script size limit), ExecJS seems to be still doing that https://github.com/sstephenson/execjs/blob/1e87b3735176c6e656e4b5ba18ed10214b321ba5/lib/execjs/ruby_rhino_runtime.rb#L68-75 which I guess is the cause of this as Rhino is forced to interpreted mode always ...

@headius

Ahh yes, the 64k limit. That's something Rhino really ought to fix, since it's not hard to reach that limit with scripts much smaller than 64k of Javascript code. A simple fix would be for it to fall back to interpreting when the script is too large. I'll investigate that.

@headius

PR filed with Rhino to fall back on interpreter when compile fails: mozilla/rhino#76

@kares
Collaborator

So, I dealt with this in the gem itself instead of waiting for Rhino ... 05ece36 (released in 2.0.2)
PRs filled to get this into less.rb cowboyd/less.rb#49 and ExecJS sstephenson/execjs#112 it gets us about a 30% performance increase - assuming compiled scripts are Rhino "byte-code generation" friendly :) ...

@kares kares closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.