I just ran rubyspec against it; ~ 5% time improvement.

WITH PATCH:

  > time mspec -t /home/kurt/local/ruby/kstephens/bin/ruby

2849 files, 13035 examples, 186461 expectations, 231 failures, 441 errors

real	4m18.626s
user	0m23.349s
sys	0m8.685s

WITHOUT PATCH:

  > time mspec -t /home/kurt/local/ruby/trunk/bin/ruby
2849 files, 13035 examples, 187339 expectations, 246 failures, 318 errors

real	4m30.655s
user	0m28.386s
sys	0m9.857s

Note the difference in failures/errors.  I don't know yet if these are 
errors due to the intended semantic difference or actual bugs.  What 
might be the best way to see the differences in object allocations and GCs?


Roger Pack wrote:
>> Yes.  The MRI test suite runs at 45 sec with these changes and at 53 sec
>> without.  The MRI tests pass with no issues.  There is a naive test in the
>> attached patch that demonstrates the improvements.
> 
> Wow that's a pretty good improvement.  I like it.
> 
> What's the speed difference for make test-all?
> 
Didn't know about test-all.  Right now test-all has some failures 
related to frozen String.  So there is still more work to be done. :(

6836 tests, 1826745 assertions, 56 failures, 248 errors, 0 skips
make: *** [yes-test-all] Error 1

real	4m23.824s
user	1m45.195s
sys	0m27.594s

>>> Does it break rails?
>> I don't know yet.  I need to setup a proper Rails test environment.
> 
> Yeah that would be nice, as well as comparing speeds for the test runs
> to see if it's useful.
> 
>> There maybe some native thread issues with the cache hash tables, but I did
>> start adding a mutex to each one.  I have not tested on 64-bit or anything
>> other that Ubunutu 9.10.
> 
> Would there be thread issues if each thread runs under the GLI?
> 
> Thanks.
> -r
>