buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Toulme <anto...@lunar-ocean.com>
Subject Re: JRuby AOT Compilation for All-in-One
Date Wed, 07 Apr 2010 20:42:15 GMT
For Buildr4OSGi, I would need to create my own distribution of Buildr that
includes the Buildr4OSGi gem. Before long, you'll get a mess. It's still a
valuable option imo.

I really thought AOT was helping. I think there was a way to build buildr as
an executable jar or something - oh well, I forgot.

On Wed, Apr 7, 2010 at 13:32, Rhett Sutphin <rhett@detailedbalance.net>wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message