Memoizing RubyObject's hashCode might give us the same benefits that interning Strings did, but the JVM may already do this for the default hashCode impl.
Based on previous work we did with identityHashCode, it is certain to be slower than a memoized version, but cheaper than one calculated every time hashCode is called. Choose wisely.
On 6/18/06, Ola Bini <[EMAIL PROTECTED]> wrote:
Yep, it seems to be zero-sum.
I'm not sure where all those HashMap.get came from in RDoc though.
Regarding RubyObject, I don't really understand why user defined classes
would generate the same string alot, since identityHashCode is used in
the default to_s.
>From that information, it would probably be safe to use identityHashCode
as the default hashCode, if we just change this behaviour for all core
objects.
But yes, I think just removing hashCode from RubyObject may be the best
solution.
Btw, in RubyString, you could just use chars.hashCode() immediatly, so
you get one method-call less, and since strings are very common this
will be a good change.
This thing with hashCode explains one of the reasons that ObjectSpace
was so darn slow, also...
My changes were almost exactly the same as yours, except for a few
differences, and it made a huge impact on RDoc at least. I think if we
do this correctly, we'll get a real boost in general performance.
/O
----- Original Message -----
From: Thomas E Enebo <[EMAIL PROTECTED]>
Date: Sunday, June 18, 2006 4:03 pm
Subject: Re: [Jruby-devel] JRuby, RDoc and speed...
To: [EMAIL PROTECTED], jruby-devel@lists.sourceforge.net
> I played with this a bit yesterday too. I left RubyObject
> hashCode the
> way it was. Then set a breakpoint there. Then ran scripts. When
> I saw
> a core class which used it I would add a hashCode impl that did what
> ever they had for 'hash'. If they didn't have anything I used
> System.identityHashCode. This all worked fine. I believe it is
> also a zero-sum change.
>
> My observations on this is that Rail/webrick startup probably
> only hit
> hashCode like 60-70 times (I am ignoring the stuff JRuby did as
> part of
> startup - Each ENV var would generate 2 calls during startup). I am
> guessing rubygems rdoc hits this a lot.
>
> Do you know how many of these hashCode calls in the rubygems
> scenarioyou mentioned was from user-defined classes versus core
> ones? My patch
> would obviously not help those. I would be extremely hesitant to
> considertoString() as part of the hashing algorithm. Consider user-
> defined classes
> I think those would generate the same string a lot (look at
> RubyObject'stoString() impl).
>
> We could memoize RubyObject hash impl at the cost of an extra int
> in every
> object (its not like we are space efficient right now anyways.
>
> Or we could even remove hashCode from RubyObject all together and
> say all Ruby object by default have the same hash as the java object
> holding their state? The JVM may even optimize for this.
>
> I will throw my patch out just for sake of comparison.
>
> -Tom
>
> On Sun, 18 Jun 2006, Ola Bini defenestrated me:
> > Hi,
> >
> > Yes, of course that's needed. But on the other hand, the change
> actually> already found us a place where our test code was wrong
> (see my post on
> > TestRubyHash). Incidentally, my first approach was to try and see
> how> System.identityHashCode() would work out as the general
> > hashCode-algorithm. I've been using rubygems setup, gem install
> and the
> > rails script as different tests to see if the changes break
> anything,> and it was very apparent when I changed to
> identityHashCode that nothing
> > at all worked. With my current changes everything seems really
> fine, though!
> >
> > /O
> >
> > ----- Original Message -----
> > From: Charles O Nutter <[EMAIL PROTECTED]>
> > Date: Sunday, June 18, 2006 6:22 am
> > Subject: Re: [Jruby-devel] JRuby, RDoc and speed...
> > To: jruby-devel@lists.sourceforge.net
> >
> > > This is pretty promising; we need to do an audit of how all the
> > > core objects
> > > are used in various places, however, especially in our
> > > implementation of
> > > Ruby's hash, so we're not breaking anything; but it has always
> > > bothered me
> > > that java's hashCode and Ruby's hash were synonymous in JRuby.
> This
> > > lookslike a good first step, and ought to help performance in a
> > > number of places.
> > >
> > > On 6/17/06, Ola Bini <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi
> > > >
> > > > I've done a few easy things to try to speed up JRuby, when
> doing
> > > RDoc. I
> > > > have three timings for you today. The first one is C Ruby
> doing
> > > it. The
> > > > second is recent JRuby without my new enhancements, and the
> third
> > > is my
> > > > final version right now:
> > > >
> > > > [EMAIL PROTECTED] /cygdrive/d/project/jruby
> > > > $ time ruby d:/programming/ruby/bin/gem install rake
> > > > Attempting local installation of 'rake'
> > > > Successfully installed rake, version 0.7.1
> > > > Installing RDoc documentation for rake-0.7.1...
> > > >
> > > > real 0m13.915s
> > > > user 0m0.000s
> > > > sys 0m0.000s
> > > >
> > > > [EMAIL PROTECTED] /cygdrive/d/project/jruby
> > > > $ time bin/jruby.bat bin/gem install rake
> > > > Attempting local installation of 'rake'
> > > > Successfully installed rake, version 0.7.1
> > > > Installing RDoc documentation for rake-0.7.1...
> > > >
> > > > real 1m42.985s
> > > > user 0m0.000s
> > > > sys 0m0.010s
> > > >
> > > > [EMAIL PROTECTED] /cygdrive/d/project/jruby
> > > > $ time bin/jruby.bat bin/gem install rake
> > > > Attempting local installation of 'rake'
> > > > Successfully installed rake, version 0.7.1
> > > > Installing RDoc documentation for rake-0.7.1...
> > > >
> > > > real 0m59.946s
> > > > user 0m0.000s
> > > > sys 0m0.010s
> > > >
> > > > As you can see, C Ruby does this in about 14s, old JRuby in
> 100s
> > > and my
> > > > new
> > > > version in 60s. For these purposes we are only 5 times slower
> > > than C Ruby,
> > > > half a magnitude. =)
> > > >
> > > > So, what was the "error" in the former version? I'll let the
> code
> > > speak> for
> > > > itself. This is from RubyObject:
> > > > public final int hashCode() {
> > > > return RubyNumeric.fix2int(callMethod("hash"));
> > > > }
> > > >
> > > > Yes, you read that right. We call a Ruby-method for EVERY
> > > HashMap#get,> HashMap#put and HashSet#add etc... Not even a
> > > memoized version. And those
> > > > operations are used fairly heavy in JRuby. HashMap#get is on
> the
> > > top 5
> > > > time
> > > > thieves accord to hprof.
> > > >
> > > > So, I replaced the former with this in RubyObject:
> > > > public int hashCode() {
> > > > return toString().hashCode();
> > > > }
> > > >
> > > > and added very simple new ones to
> > > > RubyArray.java
> > > > RubyBignum.java
> > > > RubyDir.java
> > > > RubyFile.java
> > > > RubyFixnum.java
> > > > RubyHash.java
> > > > RubyModule.java
> > > > RubyString.java
> > > > RubyThread.java
> > > > RubyTime.java
> > > >
> > > > ... Right now my source tree is slightly unclean, so I can't
> give
> > > a patch
> > > > for these modifications, but everyone of the is very simple.
> I
> > > just call
> > > > hashCode on the value object inside the object most times.
> > > RubyModule uses
> > > > classId == null ? 0 : classId.hashCode(); ... and RubyThread
> uses> > > threadImpl.hashCode().
> > > >
> > > > Regards
> > > > Ola Bini
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Jruby-devel mailing list
> > > > Jruby-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/jruby-devel
> > > >
> > >
> > >
> > >
> > > --
> > > Charles Oliver Nutter @ headius.blogspot.com
> > > JRuby Developer @ jruby.sourceforge.net
> > > Application Architect @ www.ventera.com
> > >
> >
> >
> > _______________________________________________
> > Jruby-devel mailing list
> > Jruby-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jruby-devel
>
> --
> + http://www.tc.umn.edu/~enebo +---- mailto:[EMAIL PROTECTED] ----+
> | Thomas E Enebo, Protagonist | "Luck favors the prepared |
> | | mind." -Louis Pasteur |
>
_______________________________________________
Jruby-devel mailing list
Jruby-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jruby-devel
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
_______________________________________________ Jruby-devel mailing list Jruby-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jruby-devel
