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
