From: ts Date: 2003-03-30T02:27:22+09:00 Subject: Re: Ruby 1.6.8 vs Ruby 1.8.0 preview 2 - benchmarks >>>>> "g" == gabriele renzi writes: g> why this changes had been applied? Well, if I'm right (don't forget that I'm stupid) and if one reason for the slowdown is the call to rb_equal() then it's easy to understand the change Imagine that in your source you have different classes and for these classes by default #== and #=== are the same method you can write rb_define_method(rb_cKernel, "===", rb_equal, 1); rb_define_method(rb_cA, "==", a_equal, 1); rb_define_method(rb_cA, "===", a_equal, 1); /* ... */ rb_define_method(rb_cB, "==", b_equal, 1); rb_define_method(rb_cB, "===", b_equal, 1); /* ... */ Then you think that it's just stupid and you write rb_define_method(rb_cKernel, "===", rb_equal, 1); rb_define_method(rb_cA, "==", a_equal, 1); /* ... */ rb_define_method(rb_cB, "==", b_equal, 1); /* ... */ and you rely on the fact that rb_equal() will call #== but now when you call A#=== ruby first call Kernel#=== which call A#==, rather than calling directly A#=== If this method is frequently called you can see the difference. Probably another reason is that Kernel#=== was modified, in 1.6 Kernel#=== is the same than Kernel#== (rb_obj_equal()) and don't call rb_equal() and the classes must define #=== if they want a different behavior that Kernel#=== This is why I don't trust benchmark, they show artificial things which don't reflect fatally what you use in a script Guy Decoux