I'm pretty sure this regression occurs those last 3/4 weeks as I remembered I tested it and it wasn't that slow.
If that is of any help here is how the jar is assembled: https://github.com/rvalyi/terminatooor (build.xml and 'ant' task)

Hope this helps. Don't hesitate if you have question, I'm aslo rvalyi on twitter for fast feedback.

I also tried to change a bit the ooor.gemspec to see if I was doing something wrong, but nothing improved the performance.
One reason require "activeresource" is fast might be because activeresource uses autoload while ooor doesn't. Well may be.

Still, I can tell you that if you take that same ooor gem and but it in your JRuby gems, if you try to require 'ooor' in jirb directly instead, well, it's just normally fast.

So the differences I see here is that our gems are in a jar and may be the fact that we passed through the JSR223 though I doubt it the reason of the slowness.

Raphael Valyi
added a comment - 12/Feb/11 1:19 PM Guys,
I did some further testing:
the slowness really all comes from the require "ooor" statement line 17 of https://github.com/rvalyi/terminatooor/blob/master/src/com/akretion/kettle/steps/terminatooor/ui/jirb_swing.rb
I changed a bit that part of the code of that file into:
puts Time.now()
require 'rubygems'
puts Time.now()
require 'active_resource'
puts Time.now()
require 'ooor'
puts Time.now()
This gives me:
rvalyi@rvalyi-laptop:~/DEV/terminatooor/terminatooor$ java -jar jruby-ooor.jar
Sat Feb 12 16:57:36 -0200 2011
Sat Feb 12 16:57:37 -0200 2011
Sat Feb 12 16:57:38 -0200 2011
Sat Feb 12 16:58:17 -0200 2011 (require 'ooor' was the slow part)
I also tried to change a bit the ooor.gemspec to see if I was doing something wrong, but nothing improved the performance.
One reason require "activeresource" is fast might be because activeresource uses autoload while ooor doesn't. Well may be.
Still, I can tell you that if you take that same ooor gem and but it in your JRuby gems, if you try to require 'ooor' in jirb directly instead, well, it's just normally fast.
So the differences I see here is that our gems are in a jar and may be the fact that we passed through the JSR223 though I doubt it the reason of the slowness.

Ok, Tom gave me the idea to use JarFile for the top-level jars, which reduces the cache memory load immensely. I've pushed that change, and the "require 'openssl'" example now loads slightly faster, but uses only a couple MB more than the scanning version. I find that totally acceptable.

I'm also going to look into ways to make JarFile work against in-memory resources (it normally only works against files), which would allow us to only cache JarFile.

Charles Oliver Nutter
added a comment - 03/Mar/11 11:18 AM Ok, Tom gave me the idea to use JarFile for the top-level jars, which reduces the cache memory load immensely. I've pushed that change, and the "require 'openssl'" example now loads slightly faster, but uses only a couple MB more than the scanning version. I find that totally acceptable.
I'm also going to look into ways to make JarFile work against in-memory resources (it normally only works against files), which would allow us to only cache JarFile.
commit 2f624eeb4249507cab453cbd61b3665f935be78a
Author: Charles Oliver Nutter <headius@headius.com>
Date: Thu Mar 3 11:15:58 2011 -0600
Improve jar-in-jar cache memory use by not caching contents of jars directly on the filesystem.

Nick Sieger
added a comment - 03/Mar/11 11:49 AM Unfortunate that making something work better exposes a performance issue, but nice that we can fix it as well. Patches look good so far, and looking forward to seeing this in action.

Regarding our use case, the only advantage of packaging my gems in jruby-complete is to provide a single click experience to the user. We only need SSL connections eventually from within the ETL so I just moved those SSL gems outside the jar and it works perfect, at least for us. Once again thanks a ton for your support!

Raphael Valyi
added a comment - 03/Mar/11 11:54 AM Charles,
Regarding our use case, the only advantage of packaging my gems in jruby-complete is to provide a single click experience to the user. We only need SSL connections eventually from within the ETL so I just moved those SSL gems outside the jar and it works perfect, at least for us. Once again thanks a ton for your support!

There's no way to use JarFile or ZipFile against in-memory resources, since they depend on zlib which only works against files. There are some other options that could perhaps be modified to work against in-memory resources (like Apache Harmony's java.util.zip stuff), but that's a much larger job than I want to take on.

The modified jar-in-jar logic works like this:

For top-level file: jar files, open them directly and use JarFile to get entries. Nothing from top-level jar files is cached in memory.

For nested jar files, open once and cache all contents directly in memory. There's a memory impact from this, the uncompressed contents are held in memory forever. However, nested jars are generally not too large, and the memory tradeoff comes with a very solid improvement in lookup performance.

With the new logic, only nested jars will have a memory impact equal to their uncompressed size, but the load time for resources when jars-in-jars are present is as fast as loading from filesystem jars.

Charles Oliver Nutter
added a comment - 03/Mar/11 11:56 AM Ok, I think I'm going to call this one fixed.
There's no way to use JarFile or ZipFile against in-memory resources, since they depend on zlib which only works against files. There are some other options that could perhaps be modified to work against in-memory resources (like Apache Harmony's java.util.zip stuff), but that's a much larger job than I want to take on.
The modified jar-in-jar logic works like this:
For top-level file: jar files, open them directly and use JarFile to get entries. Nothing from top-level jar files is cached in memory.
For nested jar files, open once and cache all contents directly in memory. There's a memory impact from this, the uncompressed contents are held in memory forever. However, nested jars are generally not too large, and the memory tradeoff comes with a very solid improvement in lookup performance.
With the new logic, only nested jars will have a memory impact equal to their uncompressed size, but the load time for resources when jars-in-jars are present is as fast as loading from filesystem jars.

That sounds like a fine workaround, and if you want to move them back into the jar after RC3 that will work too. Because the main part of the memory hit was from the top-level jruby-complete jar itself, I've just switched over to using the caching logic only.

Charles Oliver Nutter
added a comment - 03/Mar/11 12:55 PM Raphael: I think we were commenting at exactly the same time
That sounds like a fine workaround, and if you want to move them back into the jar after RC3 that will work too. Because the main part of the memory hit was from the top-level jruby-complete jar itself, I've just switched over to using the caching logic only.