суббота, 26 октября 2013 г.

Кстати! Об ARC. Ну чтобы представители Embarcadero на меня не обижались...


Но о "другом"...


Where ARC can actually be slower

That ARC is faster is not true in every case. Specifically where existing MRC code has already been fine-tuned to provide the best possible performance in regards to memory usage.
This is because in some situations ARC adds additional retain/release messages that are sort of optional under MRC. This happens for example when you send a message to a selector with one or more object (id) parameters. It also happens when you receive a temporary variable from a method – it gets retained and then released even though its lifetime is short and contained. For example:
And again when sending messages to a selector which takes one or more objects as parameters:
The reason why ARC adds these additional retain/release is because above all else ARC ensures correctness. And that code is correct under MRC as well. So why don’t we usually add these additional retain/release in MRC and it still works?
Because most of us aren’t writing multi-threaded applications, and even those who do will probably not understand why they’re treading dangerously close to the edge. In multithreaded applications said object could be released between the doSomething and doAnotherThing calls – thus crashing your app. Granted, it’s rare but when it rears its ugly head, you wish you wouldn’t have to debug it.
This explains why some algorithms run slower under ARC than the same code written in MRC. I tookthis Objective-C ARC genetic algorithm and converted it to MRC to make the comparison. You’ll see in the results that the ARC version is noticably slower than the MRC version mainly because of the additional retain/release:

Комментариев нет:

Отправить комментарий