Hi, Regardig the ObjectSpace-implementation, I would recommend you to move the cleanup call to ObjectSpace#iterator() ... I think that's where most of the performance go through the roof. And it's not like those WeakReferences are a problem...
/O At 07:54 2006-06-02, you wrote: >Scratch that thing about synchronization...I think my numbers got mixed >up. It's still slow with an unsynchronized Set. > >On 6/2/06, Charles O Nutter < ><mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: >FYI, the ObjectSpace performance hit appears to come from its use of a >synchronized Set. If I modify it to use an unsynchronized Set, the numbers >approach those when I have it completely disabled. Who says >synchronization costs nothing? > >The ObjectSpace thing is particularly interesting since it would have >performance gains across the board, for all objects instantiated anywhere, >any time. > > >On 6/2/06, Charles O Nutter ><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: >Some notes on performance exploration. Most of this is based on my belief >that our core interpreter and the core native types (strings, symbols, >fixnums, etc) are a large source of our performance woes. C Ruby is able >to use extremely lightweight structs for most of these core types, and >runs blazing fast (order of magnitude faster in many cases). > >- Caching of all literal fixnums > >I tested this by holding Long objects in the AST and adding a cache to the >runtime. The results were not terribly promising, and only showed marginal >gains. >Tested with: >t = Time.now; 1_000_000.times { 1000; 2000; 3000; 4000; }; p Time.now - t >Before cache: 5.15s avg >After cache: 4.7s avg, 8% improvement > >- Caching of all literal floats > >Same solution as above, but better results. >Before cache: 18.2s avg >After cache: 5.2s avg, 71% improvement > >...However it seems unlikely that literal floats are a common performance >problem. On the other hand, Floats are so drastically slow without caching >I have to wonder if something's amiss. > >- Disable ObjectSpace > >I started tracing through our object creation versus Ruby's, and along the >way thought I'd try disabling ObjectSpace entirely. The results were >surprising. >Tested with: >t = Time.now; 1_000_000.times { '1000'; '2000'; '3000'; '4000'; }; p >Time.now - t >Before disabling: 15.65s avg >After disabling: 5.76s avg, 64% improvement > >Now we're getting somewhere. Our ObjectSpace appears to be a source of >some severe performance issues. That needs to be addressed. > >... > >In general, I think there's a lot of performance to be gained from very >small tweaks to the core interpreter and classes. Something as simple as >removing the add of an object to ObjectSpace gives a 64% improvement in >speed; minor caching tweaks can produce similar results. As a whole, each >of these little fixes and tweaks will very quickly add up. > >-- >Charles Oliver Nutter @ <http://headius.blogspot.com>headius.blogspot.com >JRuby Developer @ <http://jruby.sourceforge.net>jruby.sourceforge.net >Application Architect @ <http://www.ventera.com>www.ventera.com > > > > >-- >Charles Oliver Nutter @ <http://headius.blogspot.com>headius.blogspot.com >JRuby Developer @ <http://jruby.sourceforge.net>jruby.sourceforge.net >Application Architect @ <http://www.ventera.com>www.ventera.com > > > > >-- >Charles Oliver Nutter @ <http://headius.blogspot.com>headius.blogspot.com >JRuby Developer @ <http://jruby.sourceforge.net>jruby.sourceforge.net >Application Architect @ <http://www.ventera.com>www.ventera.com >_______________________________________________ >Jruby-devel mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/jruby-devel _______________________________________________ Jruby-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jruby-devel
