[Ironruby-core] ConvertTo vs Cast

Peter Bacon Darwin bacondarwin at googlemail.com
Tue Feb 5 03:37:35 EST 2008


Regarding the aside, you can pass Float, Bignum, Complex or any other class
you choose to define to the Fixnum#+ operator so you do need an overload
with object.  I seem to remember it then coerces the fixnum to whatever the
other type is and then calls + on the coerced object.

 

Without looking at the code I can't comment on the main thrust of the mail,
but shouldn't the local variable i be a Fixnum from the word go and
therefore call the LessThan(int, int) method anyway?

Pete

 

From: ironruby-core-bounces at rubyforge.org
[mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly
Sent: Tuesday,05 February 05, 2008 03:36
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] ConvertTo vs Cast

 

Consider the following Ruby code:

 

i = 0

while (i < 1000)

  i = i + 1

end

 

When run using IronRuby, the (i < 1000) comparison results in method
ConvertToInt32 being invoked to convert local i into an integer, however,
the i +1 operation simply casts i to be an integer.

 

(IronPython performs a cast in both cases to avoid the method call to
ConvertToInt32)

 

It appears that the difference in behaviour of these two method calls in
IronRuby is due to the fact that the first argument for the LessThan method
is not overloaded:

  public static bool LessThan(int self, int other)

  public static bool LessThan(CodeContext/*!*/ context, int self, object
other)

 

but the first argument for the Add method is overloaded:

  public static object Add(int self, int other)

  public static double Add(int self, double other)

  public static object Add(CodeContext/*!*/ context, object self, object
other)

 

Note, this only affects performance, not correctness. Eliminating the call
to ConvertToInt32 makes the program execute about 10% faster.

 

As an aside, is there really a need for an overloaded Add method with a self
of type object rather than int?

Ironically, making the types stronger in this way would make the performance
worse with the current implementation.

 

Or am I completely mistaken?

 

Cheers, Wayne.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080205/2ad65866/attachment.html 


More information about the Ironruby-core mailing list