# Code Review: NewSingletons4

**URL:** <https://www.ruby-forum.com/t/code-review-newsingletons4/169984>\
**Category:** IronRuby\
**Created:** [June 10, 2009, 10:55pm UTC](https://www.ruby-forum.com/t/code-review-newsingletons4/169984 "2009-06-10T22:55:04Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![grujildo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/94ad74/32.png) [@grujildo](https://www.ruby-forum.com/u/grujildo)\
**Post date:** [June 10, 2009, 10:55pm UTC](https://www.ruby-forum.com/t/code-review-newsingletons4/169984/1 "2009-06-10T22:55:04Z")

</div>

tfpt review “/shelveset:NewSingletons4;REDMOND\tomat”

Improves the implementation of singleton method dispatch.

1. 

```
 The previous singleton related shelveset made IRubyObject 

```

singleton methods as fast to call as regular methods. Since singletons  
of Object are frequently used in specs, in fact any top level method  
calls are dispatched to a Object singleton, it makes sense to optimize  
singletons of Object as well. So far we mapped Object to System::Object  
and Object.new produced an instance of System::Object. Since such  
instances are pretty useless in .NET - they are essentially empty  
objects that you can’t do anything with - it is not necessary to  
preserve this exact mapping. We still map the Object class to  
System::Object CLR type, but the underlying CLR type of Object instances  
is RubyObject. In pure Ruby program the difference is not observable. On  
the other hand C# programs will see the instances typed to RubyObject.

1. 

```
 Fixes 

```

[http://ironruby.codeplex.com/WorkItem/View.aspx?WorkItemId=761:](http://ironruby.codeplex.com/WorkItem/View.aspx?WorkItemId=761:) Wrong  
behavior when calling redefined methods on object instances. This is  
actually fixed by 1) but the same issue applies on CLR singletons. Let’s  
say we have a CLR class C. Once you create a singleton of any of its  
instance all rules generated for method calls whose receiver is  
_any_instance of C must check whether the receiver is a singleton object  
of C or a regular instance of C. Previously we did this check only for  
calls to singleton methods. This check is a pretty expensive weak  
dictionary lookup. One way of optimizing this is to reduce the need of  
these checks. If we are sure that no singleton method of the given name  
has been defined on any singleton of C we don’t need to emit this check  
to the rule. Of course, we need to invalidate such rule as soon as such  
method is defined.

1. 

```
 Fixes potential race conditions in singleton creation.

```

These changes improve running time of specs significantly (2x):

Before:  
core/String: Finished in 13.854385 seconds  
core/Array: Finished in 15.228523 seconds

After:  
core/String: Finished in 6.620662 seconds  
core/Array: Finished in 8.438844 seconds

Also fixes signatures of Time#+, Time#-, Time#\<=\> and File#expand\_path  
specs.

Tomas