I would like to second keeping ObjectSpace on by default. Turning it off by default would fail Test::Unit, and that may surprise a lot of people (e.g. Me :)).
I do agree that providing it as an option is worthwhile. Out of curiosity, is the object creation and ObjectSpace invocation synchronous? If so, would asynchronicity helps with the performance? I am a total newbie on this topic (Ruby or JRuby), but what if we dump all objects to a queue and process them out of order? If anyone calls iterator, they can take the performance hit at that point and wait for the queue to be emptied. If no one calls the iterator, then a background thread can be used to turn the queued objects into weak references. Is this worth considering? Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Corbin Sent: Tuesday, June 06, 2006 3:51 PM To: jruby-devel@lists.sourceforge.net Subject: Re: [Jruby-devel] ObjectSpace, again. On Monday 05 June 2006 11:20 am, Charles O Nutter wrote: > I tried a very naive version of this, just to demonstrate the performance > gain. > > First off, if you never call cleanup during add, the size of the list will > quickly grow to consume all memory. The objects the weakrefs point at will > be collected, but the weakrefs themselves will not. Some cleanup is > necessary during add, though it could probably only be run every N calls to > add. > > If we ignore this, however, and increase the heap size to allow the list to > grow, the performance gains moving to a list are still nowhere near > eliminating OS entirely: > > For test: 1_000_000.times { <four literal strings> } > normal run, 512M, OS as-is: 17.3s > sync ArrayList, 512M, OS saves weakrefs: 16.4s > sync ArrayList, 512M, OS saves objects: 22s > unsync ArrayList, 512M, OS saves weakrefs: 16.2s > unsync ArrayList pre-alloc 5M entries, 512M, OS saves weakrefs: 14.8s > normal run, 512M, OS disabled: 7s > > So what does this tell us? > > First off, maintaining any sort of list is bad...ArrayList or otherwise. > Even if we throw out things we need, like cleaning the list, and make the > list huge to begin with, it's still over 2x as slow as not maintaining a > list in the first place. > > Second, maintaining weakrefs is actually cheaper than maintaining the > objects, probably because most of them are immediately collected in this > contrived example. > > Third, it seems that nothing we do is going to reduce the cost of OS to an > unnoticeable level. Look at it logically: > > Object Creation Without OS: > - instantiate object (cheap) > - set RubyClass (cheap if we reference builtin classes directly) > - set tainting (cheap) > > Object Creation With OS: > - all of the above plus... > - list maintenance (potentially very expensive for a set or growing > arraylist) > - hashing (if using a set) (very expensive) > - WeakRef creation (cheap) > - cleanup (expensive) > > Even if we eliminate cleanup and hashing, we're still instantiating twice > as many objects and maintaining a list. > > At this point, my vote goes to OS being disabled by default, with a flag to > turn it on. I'm sorry, but you must be joking. It's an integral part of what Ruby is. Just about everyone that uses Test::Unit uses it for sure (even if they don't kinow it), and who knows what other packages need it. I don't have any specific answers for how to improve performance, but I don't think a switch is good one. _______________________________________________ Jruby-devel mailing list Jruby-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jruby-devel _______________________________________________ Jruby-devel mailing list Jruby-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jruby-devel
