buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rhett Sutphin <rh...@detailedbalance.net>
Subject Re: JRuby AOT Compilation for All-in-One
Date Wed, 07 Apr 2010 20:32:02 GMT
Hi,

On Apr 7, 2010, at 3:19 PM, Daniel Spiewak wrote:

> Actually, according to Charles Nutter, this probably isn't the best  
> idea.
> Apparently AOT compilation is mostly just good for obfuscation, it  
> doesn't
> improve performance much (if at all).  In fact, it actually hurts  
> startup
> performance because there's more bytecode to verify.  So, let's not  
> go down
> that road...  :-)
>
> Instead of AOT compilation, what we could look into is bundler (
> http://github.com/carlhuda/bundler).  This will allow us to create a  
> static
> bundle which directly references all of the gems we need without  
> actually
> loading rubygems.  This would be hugely advantageous in terms of  
> startup
> performance, and could bring us to within spitting distance of  
> Buildr on
> MRI.

Loading rubygems is what makes buildr on JRuby slow?  I thought it was  
JVM startup time.

> Unfortunately, it would also mean that gem dependencies and Buildr
> plugins packaged as gems would not work with the all-in-one  
> distribution.
> Is this a worthwhile tradeoff?  I imagine most people who would go  
> for the
> all-in-one are not going to be interested in gem-based dependencies  
> for
> precisely the same reasons.

I disagree with this.  At least some of people who want to use the all- 
in-one will be people who have acquired a bunch of source code that  
says "you need buildr to build this."  If the all-in-one doesn't allow  
extensions, then the people who provide said source code will have to  
say "you need buildr to build this, but not the one that's easy to  
install.  Sorry."

Buildr's whole architecture is oriented around its smooth  
extensibility.  That seems like something to promote, not something to  
reserve for the elite who don't choose the easiest install path.

Rhett

>
> Daniel
>
> On Wed, Apr 7, 2010 at 1:39 PM, Antoine Toulme <antoine@lunar-ocean.com 
> >wrote:
>
>> This would represent a huge performance gain for Buildr! Thanks for  
>> putting
>> it together.
>>
>> Antoine
>>
>> On Wed, Apr 7, 2010 at 11:23, Daniel Spiewak <djspiewak@gmail.com>  
>> wrote:
>>
>>> http://paste.pocoo.org/show/198856/
>>>
>>> This is a patch to run the JRuby ahead-of-time compiler against the
>>> *entire*Ruby distribution and installed gems prior to zipping for
>>> distribution.  The
>>> motivations behind this are two-fold.  First, the resulting .class  
>>> files
>>> are
>>> substantially smaller than the original .rb files and so the size  
>>> of the
>>> distributable goes down.  More importantly though, AOT compilation
>> imparts
>>> a
>>> significant performance advantage, particularly when we can apply  
>>> some
>>> optimizations.  Unfortunately, documentation seems to be limited  
>>> (read:
>>> non-existant) where it comes to tuning the AOT compiler, so I had  
>>> to just
>>> guess based on what I know of its architecture.  The settings I am  
>>> using
>>> are
>>> the same ones I've been using with the regular JRuby JIT running  
>>> Buildr
>> for
>>> more than six months, so I think they're fairly safe (and they do  
>>> yield
>>> substantial benefits).
>>>
>>> The big problem I'm having is that the compiler always seems to  
>>> return an
>>> error.  It does compile everything (except for our buildr/java/ 
>>> bdd.rb and
>>> one of Hoe's files, which cause internal exceptions), and it doesn't
>> print
>>> any errors, but regardless of what I do, the result always seems  
>>> to be an
>>> error code of 1.  Headius, if you're listening in lurk mode, we  
>>> could use
>>> some help here.  :-)
>>>
>>> Hopefully this change will help streamline our all-in-one  
>>> distribution
>> and
>>> maybe make it a compelling option even for those who are  
>>> comfortable with
>>> `gem install`.
>>>
>>> Daniel
>>>
>>


Mime
View raw message