Note: by "gem dependencies" I mean at the project level. Buildr's own gem dependencies (like Antwrap) would be in the clear.
Daniel On Wed, Apr 7, 2010 at 3:19 PM, Daniel Spiewak <djspie...@gmail.com> 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. 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. > > Daniel > > > On Wed, Apr 7, 2010 at 1:39 PM, Antoine Toulme <anto...@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 <djspie...@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 >> > >> > >
