At 04:37 26/06/2004 +0900, you wrote:
>On Friday 25 June 2004 12:13, Charles Comstock wrote:
>> Sean O'Dell wrote:
>> > On Friday 25 June 2004 09:15, ts wrote:
>> >>>>>>>"S" == Sean O'Dell <sean / celsoft.com> writes:
>> >>
>> >>S> It should be very easy to do.  I'm wondering if a C extension could
>> >>possibly S> even do this.
>> >>
>> >> You are right, a C extension can effectively crash ruby
>> >>
>> >> Read carefully hash.c and array.c and just imagine what will be the
>> >> result if one method of hash.c will be applied to an array.
>> >>
>> >> matz has one day say it in a message to ruby-talk : one information is
>> >> missing
>> >
>> > You can do all sorts of things with Ruby, I see no reason why changing an
>> > object's class would crash Ruby anymore than, say, redefining a method to
>> > something different than an object expects, or including modules in a
>> > class that don't belong there.  Just be careful of what you're doing.  I
>> > see no FUNDAMENTAL reason why you couldn't change an object's class.
>> >
>> >     Sean O'Dell
>>
>> All of those places that you can assume the underlying datatype hasn't
>> changed result in increased performance for us because there is no need
>> to double check the type.  If you have #class= then you would have added
>> overhead on a significant portion of the code for a small use case.
>> While this isn't a fundemental reason it is a logical reason why it may
>> have been avoided in the first place.  Why don't you try and make a
>> patch that allows this on your own copy and compare performance and the
>> like?
>>       Charles Comstock
>
>Ran some tests.  Ran this Ruby code, which causes the check to occur 100,000 
>times:
>
>f = File.new("testfile")
>
>time_start = Time.now
>(0..10000).each do | index |
>  f.read
>  f.seek(File::SEEK_SET, 0)
>end
>time_end = Time.now
>
>p time_end - time_start
>
>
>Most of the times were around 0.753561 seconds.
>
>Then I ran the same tests 100,000 times without the check and got times around 
>0.763882 seconds.  It really takes up no extra time at all, that I can 
>figure.  Totally negligible.
>
>        Sean O'Dell

There is a theory that says that the speed of a language
is the speed at which it manipulates Integer. I don't
necessarily agree with that theory regarding higher level
languages like Ruby. Yet I feel like it is relevant in
the case of a low level change with pervasive impacts.

As a result I feel like a benchmark with integers or
some other low level objects would tell about the impact
of your change in an interesting way compared to the
test that you ran where I suspect a lot of the time is probably spent
in the OS rather than in Ruby.

Yours,

JeanHuguesRobert

-------------------------------------------------------------------------
Web:  http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17