I'm looking through jruby-rack for the first time in a long time, and
I think there's some room for a refactoring and cleanup that might
improve performance quite a bit. Here's my notes:
* For every request, it does an evalScriptlet to load the rack servlet
wrapping stuff and prepare a rack servlet handler. This would probably
be more efficient if we only did this load logic once and just
constructed a new app/handler directly rather than through
evalScriptlet and load.
* Repeatedly access modules, etc, could be cached if we had an
additional wrapper layer around each Ruby instance in memory. Then we
could, for example, cache a reference to Rack::Handler::Servlet and
construct it directly.
* This logic is using Java integration quite a bit. We may want to
used this to tune JI logic/performance, especially wrt the interface
implementation for e.g. RackResponse and RackApplication. We may be
better served by stuffing all the data from the Java side into the
Ruby objects directly, rather than depending as much on JI to populate
them. Of course, we want JI to work well enough that this sort of case
*does* work fine.
I'm having some trouble getting it to build locally:
[INFO] Building JRuby-Rack
[INFO] task-segment: [install]
[INFO] ------------------------------------------------------------------------
[INFO] [jruby-rake:rake {execution: unpack-gem}]
[INFO] rake already installed
[WARNING] /usr/bin/rake:19: undefined method `bin_path' for Gem:Module
(NoMethodError)
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Java returned: 1
[INFO] ------------------------------------------------------------------------
[INFO] Trace
Java returned: 1
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:86)
at org.jruby.maven.RakeMojo.execute(RakeMojo.java:62)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
...
If I can get it to build I'll try to make some of these improvements.
For now I will move on to DataMapper/DataObjects and try to do some
optimization passes there.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
