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