Performance comparison of Arc and MRC

The MRC seems to have been a topic of antiquity, but I'm going to turn it around in the mood. Because, today I was asked by a question: what is the performance of Arc and MRC? Indeed, there has been no comparison before.

Let's do a test first. First we need a timing helper function, I choose to use Mach_absolute_time, the function of calculating the time difference is as follows:

Double subtracttimes (uint64_t endtime, uint64_t starttime)  {     Uint64_t difference = endtime - starttime;    static double  conversion = 0.0;    if (conversion == 0.0)  {         mach_timebase_info_data_t info;         kern_return_t err = mach_timebase_info (&info);                        // Convert the timebaseinto seconds        if (err ==  0)             conversion = 1e-9  *  (Double)  info.numer /  (double)  info.denom;    }     return conversion *  (double) difference;} 

The

Then defines two test classes, one in the ARC environment and one in the MRC environment, as follows:

 Test1.m+  (void) test {    uint64_t start,stop;     start = mach_absolute_time ();    for  (int i = 0;  i < 1000000; i++)  {        nsarray *array  = [[nsarray alloc] init];    }    stop =  mach_absolute_time ();     double diff = subtracttimes (Stop, start );     nslog (@ "arc total time in seconds = %f\n",  diff);}  Test2.m//  in Target->build phases->compile sources, add the Compile identity-fno-objc-arc+  (void ) Test {    uint64_t start,stop;    start = mach_ Absolute_time ();    for  (int i = 0; i < 1000000;  i++)  {        nsarray *array = [[nsarray alloc] init];         [array release];    }     stop = mach_absolute_time ();    double diff =  Subtracttimes (Stop, start);     nslog (@ "Mrc total time in seconds  = %f\n ",  diff);}

Run a few more sets of tests, then pick two groups to see the data as follows:

Group A arc total time in seconds = 0.077761MRC total time in seconds = 0.072469//B group Arc total time in seconds = 0.075722MRC Total time in seconds = 0.101671

From the above data can be seen, arc and MRC each have a slow situation. Even up to the point of statistics, ARC wins only with a slight advantage. It seems that my test posture is not correct, and it does not prove which side is the absolute advantage.

Well, let's see what the official documentation says. There is a passage in transitioning to ARC Release notes:

is ARC slow?

It depends on the what's your ' re measuring, but generally "no." The compiler efficiently eliminates many extraneousretain/release calls and much effort have been invested in speeding up T He objective-c runtime in general. In particular, the common "return a Retain/autoreleased object" pattern was much faster and does not actually put the OBJEC T into the autorelease pool and when the caller of that method is ARC code.

One issue to being aware of IS, the optimizer are not run in common debug configurations, so expect to see a lot more Reta In/release traffic at-o0 than At-os.

Let's take a look at other people's data. Steffen Itterheim in Confirmed:objective-c ARC is slow. Don ' t use it! (sarcasm off) a large amount of test data is given in the article. This article was published in the 2013.3.20 issue. Steffen Itterheim a conclusion through his tests.

ARC is generally faster, and arc can indeed be slower

Well, some contradictions. In the article, however, Steffen Itterheim points out that the performance of arc is better in most cases, thanks to some bottom-level optimizations and the optimization of the autorelease pool, which can be seen from official documents. But in some cases, the arc is really slower, and arc sends some extra retain/release messages, such as some where the temporary variables are involved, see the following code:

This is typical MRC code:{id object = [array objectatindex:0];    [Object dosomething]; [Object doanotherthing];}    This is what the ARC does (and what's considered best practice under MRC): {id object = [array objectatindex:0]; [Object retain];    Inserted by ARC [object dosomething];    [Object doanotherthing]; [Object release]; Inserted by ARC}

In addition, there are similar operations in the methods with object parameters:

This is typical MRC code:-(void) SomeMethod: (ID) object{[object dosomething]; [Object doanotherthing];} This was what the ARC does (and what's considered best practice under MRC):-(void) SomeMethod: (ID) object{[object retain ];    Inserted by ARC [object dosomething];    [Object doanotherthing]; [Object release]; Inserted by ARC}

These additional retain/release operations are also the culprit for reducing program performance in the ARC environment. In practice, however, these additional retain/release operations are added to ensure that the code is running correctly. If you only perform these operations in a single thread, you may not necessarily add these extra actions. But when it comes to multi-threaded operations, the problem comes. As in the above method, object is completely possible to be freed between Dosoming and Doanotherthing method invocations. To avoid this, an [object retain] is added at the beginning of the method, and the [object release] action is added after the method ends.

If you want to learn more about arc and MRC performance, you can read about the is there any concrete study of the performance impact of using arc? With ARC vs. MRC performance, in This is not too much to extract.

In fact, even if the performance of arc is not as good as MRC, we should also use arc, so its benefits to us is self-evident. We no longer need to focus too much on memory issues (although memory is a must), as with MRC, and more time on what we really care about. If you are really concerned about performance, consider using C or C + + directly. I'm not going back to the MRC anyway.

Performance comparison of Arc and MRC