Mailing-List: contact dev-help@buildr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@buildr.apache.org
Received-SPF: pass (athena.apache.org: domain of djspiewak@gmail.com
 designates 74.125.92.24 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=BGaHbPw9R9zNx6nryPghFjmrCp+9CmzNqsblxXAXDzyOEyUPfMCDUwjSqHUEpSps5m
         twu3gxn9b5jK/TCYCLJPjy7lyxV2BmRW+EcURHrESX9nCdZC27I0FShYtv6sKxBWTNUQ
         ZbBw8jVc9zH7GHoBnrA4C7oYu1VL7mjVEr2Mg=
MIME-Version: 1.0
In-Reply-To: <6BEC419E-7012-4C63-A46E-2BE7EA4B4F1F@detailedbalance.net>
References: <u2t5c99d0331004071123s156cdcap91e43301f0f14b47@mail.gmail.com>
	<h2vf97124911004071139ga7c7d614tb2d5c4487c52a1b4@mail.gmail.com>
	<p2t5c99d0331004071319y45660d10i2a145978d8a51275@mail.gmail.com>
	<6BEC419E-7012-4C63-A46E-2BE7EA4B4F1F@detailedbalance.net>
From: Daniel Spiewak <djspiewak@gmail.com>
Date: Wed, 7 Apr 2010 15:39:30 -0500
Message-ID: <t2r5c99d0331004071339se9f007a2kcab80f37127e71cf@mail.gmail.com>
Subject: Re: JRuby AOT Compilation for All-in-One
To: dev@buildr.apache.org
Content-Type: multipart/alternative; boundary=0016363b91204a5dda0483ab909e

--0016363b91204a5dda0483ab909e
Content-Type: text/plain; charset=UTF-8

> 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.


If it were just JVM startup time, you would see Ant and Maven taking just as
long to get rolling, and that just doesn't happen.

According to the JRuby team, the far-and-away top sources of slow startup
performance are Rubygems and client vs server mode JVM (in that order).
Apparently in the JRuby trunk with the JVM in -client mode, jruby -e "puts
'a'" can run in less than half a second.  Compare that to the five-ish
seconds required to get run `buildr --help`.

The whole -client JVM thing is something we can solve easily with our
all-in-one distribution since we're already using a custom startup script.
We can also add some of the unsafe optimizations I've found to be sound for
Buildr, which also helps both startup and overall performance.  However,
neither of those address the largest source of startup performance woes:
Rubygems.


>
>  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."
>

Extensions are fine, you just wouldn't be able to get them via Rubygems.  At
least, not if we do this naively.  We may be able to set things up so that
we only load Rubygems if we actually need it for a project-defined extension
or dependency.  Otherwise, if it's just vanilla Buildr, we can leave
Rubygems untouched.  This would in a sense be the best of both worlds: most
projects would get super fast Buildr startup time, while the ones that
really need Rubygems could still use it.  We might even see some performance
boost due to the fact that the JVM will be more warmed up by the time it
gets to the point where we would determine Rubygems as necessary.

Daniel

--0016363b91204a5dda0483ab909e--