[Rubycocoa-devel 1154] Re: Duck typing for NSArray and NSDictionary

Zurück zum Archiv-Index

Satoshi Nakagawa snaka****@infot*****
Mon Aug 27 02:13:26 JST 2007


Hi Laurent.

> I am working on a RubyCocoa app and found that using the duck typing  
> of NSString was causing some performance problem. The context was a  
> method that took an NSString, and then I looped lots of time to call  
> methods on the NSString. It was a lot faster to call #to_s and call  
> the String methods on the instance, rather than pass via  
> #method_missing.

Yes, it's slow.
Because it calls #to_s and #dup every time.

#to_s is for calling the Ruby method and #dup is for checking
the value is changed after calling the method.
If the value is changed (the method was destructive),
it calls #setString(new_value) for updating itself.

> I suppose that the NSArray and NSDictionary changes  
> you added will also have this problem, since they also use  
> #method_missing.

True.
NSArray and NSDictionary have the same problem as NSString.

> One thing we could do is to automatically define the missing method in  
> #method_missing. So that the next time, this will be a direct call.
>
> # This is what we currently do when messaging Ruby -> ObjC.
>
> What do you think?

It seems a different situation as described above.

If we introduced automatic definition of the missing method,
however we would need to call #to_s and #dup every time.

The major point is the cost of #to_s and #dup.
We cannot bypass it because NSString has its own value,
different from Ruby String.
When we want to call a method of Ruby String,
we need to convert NSString into Ruby String.

So I think we should port Ruby String methods to NSString
as much as possible.
It's good for performance because it doesn't need
method_missing and #to_s and #dup and #setString.

Obviously it's also applicable to NSArray and NSDictionary.
But it's easier for these types, because we need to think
about character encodings for NSString and Ruby String.

--
Satoshi Nakagawa




More information about the Rubycocoa-devel mailing list
Zurück zum Archiv-Index