Do that! I've been thinking about it for 2-3 days, and I can't really find a reason not to. The test cases all run, RubyGems, Rails and WEBrick seem to work as well as before. Can someone possibly run Rubicon and the other tests too, so we're sure about this?
As you say, it seems more Right to do it this way, so if we can't find a problem with it, I think we should do it and then fix it if there actually comes up an issue with it later on. Regards Ola ----- Original Message ----- From: Thomas E Enebo <[EMAIL PROTECTED]> Date: Sunday, June 18, 2006 4:54 pm Subject: Re: [Jruby-devel] JRuby, RDoc and speed... To: Ola Bini <[EMAIL PROTECTED]> Cc: Thomas E Enebo <[EMAIL PROTECTED]> > On Sun, 18 Jun 2006, Ola Bini defenestrated me: > > > > 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. > > Yes it is true that if no user-defined class ever overrides to_s > we are > ok. I exaggerated the case a bit... > > > >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. > > I applied a patch that does this (and this made the patch smaller). > This is no longer zero-sum, but it seems more correct to me. > > Things appear to be running fine. In one sense this seems like this > should be an improvement over what we had. Java's hashing should not > be controlled by a user-defined Ruby hash function. At least it seems > like it has a lot of potential for collisions. > > So before we consider applying this, can we think of when we NEED > 'def hash' to dictate hashCode? Like maybe (I am just making this up > to give an idea) included Javaclasses need it so that it can get its > wrapped hashCode? > > > 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. > > Good idea. I made this change. > > > This thing with hashCode explains one of the reasons that > ObjectSpace> was so darn slow, also... > > Yep. I imagine it would be. This probably would have become > more obvious if immediate objects were placed in there as well. > > > 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. > > I would like to apply this since it halved your runtime for your > testcase. I just want to make sure we are not forgetting something... > > -Tom > > -- > + 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
