Hi Charlie, What's the driving force behind this? Is this because of limitations of GAE or something else?
I've recently played with jruby-complete.jar to see how its size and compression affect the startup performance, and it turned out that uncompressed JAR is much bigger but allows to save 0.1 - 0.2 secs from startup. :) Also, using pack200 produces some pretty big size savings: Before pack: jar-complete is 10.5Mb. After pack, via pack200 -G -O jruby-complete.jar the size is 9.0Mb. Not bad. But it strips all debug info in process of repacking, and reorders files. The help says that one needs to be careful with -O command line switche though, they somehow might affect JAR access optimizations. It seems that stripping the debug info is the biggest factor that allows to reduce the size here. Thanks, --Vladimir On Sat, Oct 10, 2009 at 7:18 AM, Charles Oliver Nutter <[email protected]> wrote: > I had a few ideas for shrinking the JRuby jar file. Some are generally > useful, like for JRuby dist, but others are only useful for specific > cases uses. Wanted to get your input on them: > > * Group multiple invokers into single classes or generate switch-based > invokers for non-perf-critical cases > * Share a single invoker for all subclass overrides of a superclass > method (like only generate a single to_s invoker against > RubyBasicObject). This could impact inlining potential since a single > invoker will handle multiple target methods (where right now, inlining > through an invoker is easy). > * Remove all invokers and populators and run on reflected or > lazily-generated invokers > > Anything that reduces the number of invoker classes can be a big help. > The invoker classes, one per core class Ruby method, consume almost > 1.5MB in the compressed jar file. > > * Remove debugging symbols from all .class files (other than line > number info). Obfuscate private methods and classes to short names. > > Some libraries do both of these to reduce the size of their shipped > binaries. The former would not damage stack traces, but the latter > obviously would. > > * Remove 1.9 or 1.8-only stuff and ship a single-version jar > > With our move to 1.8.7, this isn't as helpful, but it could eliminate > some of the invokers that don't get used. > > * Remove native libraries and anything that requires them when > shipping to secured environments like applets or GAE > * Remove native libs for other platforms and only ship a specific one > (applicable more for applications targeting a specific platform) > > Removing all the native libs shrinks the compressed jar by about 250KB > or so. Our move away from JNA has helped here too. > > * Compress the jruby.jar and jruby-complete.jar with pack200. In > jruby.jar's case, unpack it the first time bin/jruby is run > > Here's the packed sizes of jruby.jar and jruby-complete.jar with no > other modifications: > > -rw-r--r-- 1 headius staff 10432321 Oct 9 23:26 jruby-complete.jar > -rw-r--r-- 1 headius staff 3975247 Oct 9 23:26 jruby-complete.pack.gz > -rw-r--r-- 1 headius staff 8028709 Oct 9 23:18 jruby.jar > -rw-r--r-- 1 headius staff 2140319 Oct 9 23:23 jruby.pack.gz > > So doing this would shrink JRuby's full dist by over 8.3MB. It's worth > noting that applets support pack200 too, so anyone shipping JRuby as > an applet should try to use pack200. > > * Use jarjar or some other tool to strip out classes we don't use, > like extra classes from joda, asm, and so on. > > Some of the classes will be difficult to accurately remove due to > reflection effects, but there could be a great untold savings. > > - Charlie > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
