On 10/5/07, Bill Dortch <[EMAIL PROTECTED]> wrote: > The variables code is/was in place in the bdortch/attrs branch, but I'm > moving it to bdortch/vars, with some changes (due in part to much > refactoring in trunk since I first wrote it). I plan to work on this tonight > and tomorrow (Saturday), and hope to finish it up by Sunday evening, if not > sooner. At that point, it will need to be reviewed and tested before being > merged to trunk. I'll write up a more detailed note Sunday, but here are a > couple of quick items: > > - The code addresses symbols, variables (ivars and cvars), and constants, > as well as internal (or "special") variables.
Can any of these special variables be moved to attrs like what was done recently by Marcin in his last big merge? Making them attributes (while perhaps not the right direction for lightweights) is much faster than hash storage. > > - In general, synchronized (or synchronized-access) HashMaps are replaced > with custom concurrent hash implementations. Also, "fast" accessors are > provided that can be used when a variable/constant/symbol name is known to > be interned. For single-threaded access, the result is 30-100% faster reads > (best improvement is for ivars; constant/cvar/symbol lookup is more > complicated, but still much faster). For multi-threaded access, the > improvement can be nX faster (I've run benchmarks that show 200-300% better > throughput). That probably won't help much for ivars, but symbol and > constant lookup should be much improved in multi-threaded applications. I think someone else asked this as well, but what is the motivation for a custom concurrent hashmap implementation? I ran your attrs branch (a few weeks ago) against the infamous rake gem install and it gave us over 10%. That is pretty sweet. > > - I had played with some initial refactoring of IRubyObject/RubyObject, but > don't plan to include that in the bdortch/vars branch. I think this *badly* > needs to be done; the current hierarchy is very rigid and forces us into > less-than-optimal implementations of built-in objects and Java objects, > among other things. (Even without going as far as "lightweight" > implementations, there is no reason a RubyFixnum, for example, should need > to carry fields for flags, dataStructs, finalizers, instance variables, and > so on.) But I think this will need to wait until after 1.1 -- it will be a > big change, will likely break external/3rd party code, and needs discussion > and debate. Perhaps we should start a thread or JIRA (or some other forum > -- Google doc? group?) on JRuby 1.x architecture. I've got a few other > notions on the subject, more on this later. I think a thread in our existing mailing list is fine. We can use the wiki for any artifacts we create. I like the idea of hashing out this stuff and getting some consensus. I also like putting it off IRubyObject changes until after 1.1 (a month to polish what we have). I suppose anything which radically affects major interfaces/classes probably should be 2.0 material... -Tom -- Blog: http://www.bloglines.com/blog/ThomasEEnebo Email: [EMAIL PROTECTED] , [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
