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