Переквалификация c#-> ??

[dotcom]

Мягко скажем оверхед на размер счетчика, да на каждый объект...

Единственный серьезный overhead в ObjC, что кстати начинающие не особо себе представляют, - это механизм обработки сообщений объектами. Динамический язык и все такое, но из-за этого Apple настойчиво засовывает блоки в те места, где критична производительность, потому что посылки сообщений/вызов методов у объектов - вещь медленная.

[Интеррапт]

Мягко скажем оверхед на размер счетчика, да на каждый объект...

Единственный серьезный overhead в ObjC, что кстати начинающие не особо себе представляют, - это механизм обработки сообщений объектами. Динамический язык и все такое, но из-за этого Apple настойчиво засовывает блоки в те места, где критична производительность, потому что посылки сообщений/вызов методов у объектов - вещь медленная.

Правильно, медленней чем C, за счет того, что фактически каждый вызов - это вызов виртуального метода. Но ведь это C. Если видишь, что какие-то методы критичны по скорости вызова, то просто выносишь их из интерфейса и имплементируешь как обычную Си функцию (включая возможность использования inline). Ведь полная прозрачность между Objective-C, C, C++.

но из-за этого Apple настойчиво засовывает блоки в те места, где критична производительность

Не только из-за этого. Блоки просто удобней в качестве каллбеков. Просто раньше блоков не было в Objective-C, это относительно новая фича языка. Хотя это даже не Objective-C фича, а Эппловское расширение для C.

[dotcom]

Правильно, медленней чем C, за счет того, что фактически каждый вызов - это вызов виртуального метода.

Нет, вызовы в ObjC еще менее эффективны, чем вызов виртуального метода через vtbl. Посмотри на код в obj_msgSend. Я уверен, что у тебя там отладчик часто падал. Но все же. Каждое сообщение/метод - это строка. Ее надо схешировать, найти в lookup'е ссылку и вызывать. Хэш остается в кэше методов, но это, как ни крути, все равно медленно.

Не только из-за этого. Блоки просто удобней в качестве каллбеков. Просто раньше блоков не было в Objective-C, это относительно новая фича языка. Хотя это даже не Objective-C фича, а Эппловское расширение для C.

Да, все правильно. Callback'и легко делаются как делегаты, т.е. ссылки на объект и его селектор. Т.е. концепция callback'а там была давно. Блоки - это еще и быстрый callback/closure и lambda в одном флаконе.

[Интеррапт]

Нет, вызовы в ObjC еще менее эффективны, чем вызов виртуального метода через vtbl. Посмотри на код в obj_msgSend. Я уверен, что у тебя там отладчик часто падал. Но все же. Каждое сообщение/метод - это строка. Ее надо схешировать, найти в lookup'е ссылку и вызывать. Хэш остается в кэше методов, но это, как ни крути, все равно медленно.

Чем-то мне это напоминает "клейсер - это клей" Ну так я же не спорю и не пытаюсь сравнивать Objective-C и C++ по эффективности вызовов. То, что я пытаюсь донести, что в большинстве случаев performance вызова методов в Objective-C очень даже на уровне, а там где нужно, метод всегда можно вынести как С функцию и спокойно вызывать ее из Objective-C кода. Благо, что не нужен никакой JNI, как в случае с джавой. Сишный (или C++) код спокойно вставляется прямо в исходник Objective-C файла. Это даже не считая того, что в LLVM 4.2 вроде как куча оптимизаций для вызова objective-c методов.

Да, все правильно. Callback'и легко делаются как делегаты, т.е. ссылки на объект и его селектор. Т.е. концепция callback'а там была давно. Блоки - это еще и быстрый callback/closure и lambda в одном флаконе.

Ну елки, ес-но каллбеки были давно, через вызовы делегатов Что я говорю, что blocks - это коллбеки на уровне С, даже не Objective-C, с соответствующим почти нулевым оверхедом. Да и просто синтаксис удобней.

[Интеррапт]

Нет, вызовы в ObjC еще менее эффективны, чем вызов виртуального метода через vtbl. Посмотри на код в obj_msgSend. Я уверен, что у тебя там отладчик часто падал. Но все же.

Ну так я же не спорю и не пытаюсь сравнивать Objective-C и C++ по эффективности вызовов. То, что я пытаюсь донести, что в большинстве случаев performance вызова методов в Objective-C очень даже на уровне, а там где нужно, метод всегда можно вынести как С функцию и спокойно вызывать ее из Objective-C кода. Благо, что не нужен никакой JNI, как в случае с джавой. Сишный (или C++) код спокойно вставляется прямо в исходник Objective-C файла. Это даже не считая того, что в LLVM 4.2 вроде как куча оптимизаций для вызова objective-c методов.

Каждое сообщение/метод - это строка. Ее надо схешировать, найти в lookup'е ссылку и вызывать. Хэш остается в кэше методов, но это, как ни крути, все равно медленно.

В большинстве случаев, метод, который уже вызывался - будет закеширован и выполнится с такой же скоростью как вызов virtual method (cache lookup - это inlined код). А если методы вызывался только один раз, кому интересно, что он вызвался медленней, чем virtual method.

https://developer.apple.com/library/mac ... -CH104-SW2 (блин, в Привете длинные ссылки не работают)

To speed the messaging process, the runtime system caches the selectors and addresses of methods as they are used. There’s a separate cache for each class, and it can contain selectors for inherited methods as well as for methods defined in the class. Before searching the dispatch tables, the messaging routine first checks the cache of the receiving object’s class (on the theory that a method that was used once may likely be used again). If the method selector is in the cache, messaging is only slightly slower than a function call. Once a program has been running long enough to “warm up” its caches, almost all the messages it sends find a cached method. Caches grow dynamically to accommodate new messages as the program runs.

Да, все правильно. Callback'и легко делаются как делегаты, т.е. ссылки на объект и его селектор. Т.е. концепция callback'а там была давно. Блоки - это еще и быстрый callback/closure и lambda в одном флаконе.

Ну елки, ес-но каллбеки были давно, через вызовы делегатов Что я говорю, что blocks - это коллбеки на уровне С, даже не Objective-C, с соответствующим почти нулевым оверхедом. Да и просто синтаксис удобней.

[crypto5]

Т.е. в отдельном участке кода вы не сильно знаете удалится обьект после выхода из области видимости или нет? Это к детерменизму.

Я абсолютно точно знаю, когда и где удалится обьект в Objective-C.

Откуда?

Что откуда? Потому что ARC упрощает подсчет ссылок, но это всегда можно сделать вручную. Можно вообще не пользоваться ARC и использовать retain/release для ручного менеджмента памяти. Можно использовать вообще гибридных подход. Но даже с ARC - программист всегда может точно сказать, когда его обьект удалится. Можно даже в любой посмотреть, вызвав метод retainCount, сколько активных references существует для данного обьекта.
Мне верить не обязательно, просто почитайте про memory management для Objective-C.

Я так и не понял откуда у вас знания что на обьект нету ссылок в 20-и других местах, или например цикличных ссылок с которыми ARC не может справится.
Как вам помогает retainCount? Как именно вы его используете? Вернул он число 5 в рантайме, и что дальше?
Ну и вопрос в сторону, у вас были реальные проблемы с паузами от джавовского GC?

[Интеррапт]

Я так и не понял откуда у вас знания что на обьект нету ссылок в 20-и других местах, или например цикличных ссылок с которыми ARC не может справится.

В смысле? Если я создаю обьект и манипулирую им, то я точно знаю, когда этот обьект будет реально удален из памяти. А вы, используя Джаву этого знать точно не можете. А есть ссылки на обьект или нет, я так точно всегда знаю. Например, передавая обьект какому-то методу там или задокументировано, что будет создан дополнительный рефернс на обьект или я всегда могу проверить опытным путем, изменился ли ref counter у этого обьекта. Вы забываете, что в Objective-C полностью ручная модель управления памятью, которая ничем от C++ не отличается (если брать C++ с подсчетом ссылок), кроме того, что в Objective-C были добавлены системы автоматизации подсчета ссылок (ARC). Давайте проведем исследование, вы напишите любой код на Objective-C, а я вам в точности расскажу когда такой-то обьект будет удален из памяти. Включая даже с описанием, когда autorelease pool удаляется и соответственно вместе с ним удаляются все переменные. А затем вы напишите код на Джаве и обьясните мне, когда конкретно ваш обьект удалится.
И самое главное, что в Objective-C это особо и не нужно, все что нужно знать, что если ты создал обьект, то тебе ему нужно будет сделать release (если речь идет о коде без ARC, т.к. ARC это делает автоматом, когда обьект выходит из области видимости). И что когда удалятся все обьекты, у которых есть ссылки на твой обьект, тот тут же произойдет освобождение памяти твоего обьекта. И это все очень легко прогнозируемо. Т.е. выходит обьект из области видимости - счетчик уменьшается на 1. Уменьшился до нуля, тут же удалился, а не ждет, чтобы gc это сделал. Что же тут сложного понять?

Насчет цикличных ссылок, так в Objective-C специально для этого есть weak properties и все отлично Objective-C с этим справляется, не выдумывайте. Да и даже до появления weak properties все вполне работало с assign property или с обнулением ссылок в десктрукторе класса. Проблема была в том, что некоторые делегаты обьявлялись как retain и тогда их нужно было обнулять в деструкторе класса. Этого уже давно нет, с появляением weak типа.

Ну и вопрос в сторону, у вас были реальные проблемы с паузами от джавовского GC?

В играх. В андроидовских. Вы думаете от хорошей жизни куча игровых движков на С++ под Андроид пишутся?

[Интеррапт]

Вот вам пример:

Code: Select all

- (void)coolSelector
{
   MyObject* obj = [[MyObject alloc] init];
   ...
}

так вот, под ARC - удаление памяти (и вызов деструктора dealloc) для обьекта obj произойдет ровно в тот момент, когда coolSelector закончит выполнение. Без ARC нужно будет написать

Code: Select all

- (void)coolSelector
{
   MyObject* obj = [[MyObject alloc] init];
   ...
   [obj release];
}

ну а собственно если передаешь этот обьект куда-то, например в NSArray, то в NSArray будет добавлен reference на этот обьект. Соответственно удален из памяти этот обьект при выходе из coolSelector не будет. Зато если будет удален NSArray, то тут же и будет удален ваш обьект obj, включая вызов деструктора и т.п. Все абсолютно на 100% прогнозируемо.
Вы действительно никогда не работали C++-ными shared_ptr, что задаете такие простые вопросы? А тут тот же самый shared_ptr, только на уровне компилятора (ну и помощнее в своей реализации).

[M. Ridcully]

То-ли Привет глючит, то ли я темой ошибся...

[Интеррапт]

Я так и не понял откуда у вас знания что на обьект нету ссылок в 20-и других местах, или например цикличных ссылок с которыми ARC не может справится.

В смысле? Если я создаю обьект и манипулирую им, то я точно знаю, когда этот обьект будет реально удален из памяти. А вы, используя Джаву этого знать точно не можете. А есть ссылки на обьект или нет, я так точно всегда знаю. Например, передавая обьект какому-то методу там или задокументировано, что будет создан дополнительный рефернс на обьект или я всегда могу проверить опытным путем, изменился ли ref counter у этого обьекта. Вы забываете, что в Objective-C полностью ручная модель управления памятью, которая ничем от C++ не отличается (если брать C++ с подсчетом ссылок), кроме того, что в Objective-C были добавлены системы автоматизации подсчета ссылок (ARC). Давайте проведем исследование, вы напишите любой код на Objective-C, а я вам в точности расскажу когда такой-то обьект будет удален из памяти. Включая даже с описанием, когда autorelease pool удаляется и соответственно вместе с ним удаляются все переменные. А затем вы напишите код на Джаве и обьясните мне, когда конкретно ваш обьект удалится.
И самое главное, что в Objective-C это особо и не нужно, все что нужно знать, что если ты создал обьект, то тебе ему нужно будет сделать release (если речь идет о коде без ARC, т.к. ARC это делает автоматом, когда обьект выходит из области видимости). И что когда удалятся все обьекты, у которых есть ссылки на твой обьект, тот тут же произойдет освобождение памяти твоего обьекта. И это все очень легко прогнозируемо. Т.е. выходит обьект из области видимости - счетчик уменьшается на 1. Уменьшился до нуля, тут же удалился, а не ждет, чтобы gc это сделал. Что же тут сложного понять?

Насчет цикличных ссылок, так в Objective-C специально для этого есть weak properties и все отлично Objective-C с этим справляется, не выдумывайте. Да и даже до появления weak properties все вполне работало с assign property или с обнулением ссылок в десктрукторе класса. Проблема была в том, что некоторые делегаты обьявлялись как retain и тогда их нужно было обнулять в деструкторе класса. Этого уже давно нет, с появляением weak типа.

Ну и вопрос в сторону, у вас были реальные проблемы с паузами от джавовского GC?

В играх. В андроидовских. Вы думаете от хорошей жизни куча игровых движков на С++ под Андроид пишутся?

[crypto5]

Я так и не понял откуда у вас знания что на обьект нету ссылок в 20-и других местах, или например цикличных ссылок с которыми ARC не может справится.

В смысле? Если я создаю обьект и манипулирую им, то я точно знаю, когда этот обьект будет реально удален из памяти.

В helloworld-e может быть

Например, передавая обьект какому-то методу там или задокументировано, что будет создан дополнительный рефернс на обьект или я всегда могу проверить опытным путем, изменился ли ref counter у этого обьекта.

Это прекрассно. Вы работаете исключительно с кодом который документирует такие подробности? Вы проверяете refCount для каждого бренча выполнения программы?

Давайте проведем исследование, вы напишите любой код на Objective-C, а я вам в точности расскажу когда такой-то обьект будет удален из памяти.

https://github.com/robbiehanson/XMPPFra ... /XMPPJID.m строка 95, переменная preUser.

А затем вы напишите код на Джаве и обьясните мне, когда конкретно ваш обьект удалится.

Не нужно мне приписывать слов которых я не говорил, я не утверждал что в джаве детерменированный GC

И самое главное, что в Objective-C это особо и не нужно, все что нужно знать, что если ты создал обьект, то тебе ему нужно будет сделать release (если речь идет о коде без ARC, т.к. ARC это делает автоматом, когда обьект выходит из области видимости). И что когда удалятся все обьекты, у которых есть ссылки на твой обьект, тот тут же произойдет освобождение памяти твоего обьекта. И это все очень легко прогнозируемо. Т.е. выходит обьект из области видимости - счетчик уменьшается на 1. Уменьшился до нуля, тут же удалился, а не ждет, чтобы gc это сделал. Что же тут сложного понять?

С чего вы взяли что эти заурядности для меня сложны в плане понимания?

Насчет цикличных ссылок, так в Objective-C специально для этого есть weak properties и все отлично Objective-C с этим справляется, не выдумывайте. Да и даже до появления weak properties все вполне работало с assign property или с обнулением ссылок в десктрукторе класса.

ВЫ никогда не сталкивались с багами в программах?

Ну и вопрос в сторону, у вас были реальные проблемы с паузами от джавовского GC?

В играх. В андроидовских.

И как вы определили что проблема была в GC? В интернетах пишут что concurrent mark останавливает приложение на 5мс

Вы думаете от хорошей жизни куча игровых движков на С++ под Андроид пишутся?

Думаю что у Ц++ выше row производительность, особенно в сравнении с давликом, и он возможно имеет доступ к каким то экстра АПИ

[crypto5]

Вот вам пример:

Code: Select all

- (void)coolSelector
{
   MyObject* obj = [[MyObject alloc] init];
   ...
}

так вот, под ARC - удаление памяти (и вызов деструктора dealloc) для обьекта obj произойдет ровно в тот момент, когда coolSelector закончит выполнение. Без ARC нужно будет написать

Code: Select all

- (void)coolSelector
{
   MyObject* obj = [[MyObject alloc] init];
   ...
   [obj release];
}

ну а собственно если передаешь этот обьект куда-то, например в NSArray, то в NSArray будет добавлен reference на этот обьект. Соответственно удален из памяти этот обьект при выходе из coolSelector не будет. Зато если будет удален NSArray, то тут же и будет удален ваш обьект obj, включая вызов деструктора и т.п. Все абсолютно на 100% прогнозируемо.
Вы действительно никогда не работали C++-ными shared_ptr, что задаете такие простые вопросы? А тут тот же самый shared_ptr, только на уровне компилятора (ну и помощнее в своей реализации).

И к чему этот пример? Как я уже написал в этом случае джава с помощью escape analysis тоже с большой вероятностью выделит этот обьект на стеке и кильнет его при выходе из метода.

[Интеррапт]

В helloworld-e может быть

Нет, в любом приложении.

https://github.com/robbiehanson/XMPPFra ... /XMPPJID.m строка 95, переменная preUser.

Ну, preUser будет уничтожена после того, как выйдет из области видимости этого самого "parse" метода (в случае ARC, а без ARC - будет отложена в autorelease pool и уничтожена вместе с другими autorelease переменными при уничтожении autorelease pool, что произойдет к концу event loop). Мало того, даже без использования ARC я могу тело этого parse метода поместить в @autorelease блок и точно знать, что эта самая переменная preUser будет уничтожена при выходе из @autorelease блока, даже без завершения event loop. А к чему вы спрашиваете? Даже если предположить, что этот вызываемый в 95-й строке метод где-то скрывает какие-то хитрые функции, вроде как хранит собственную ссылку на возвращаемое значение (что может произойти, если LibIDN, например, возвращает какие-то кешируемые значения), то все равно, оно будет уничтожено сразу же как LibIDN выйдет из области видимости. И ведь самое главное, что я могу breakpoint поставить на эту перменную и посмотреть ее reference count. Все на 100% детерминировано.

[Интеррапт]

И к чему этот пример? Как я уже написал в этом случае джава с помощью escape analysis тоже с большой вероятностью выделит этот обьект на стеке и кильнет его при выходе из метода.

Escape analysis делает это для довольно простых случаев. А objective-c сделает это для любых случаев. Да и вот вы написали "с вероятностью", т.е. предугадать никогда не можете. А в случае с Objective-C я на 100% знаю, что произойдет с удалением обьекта и когда это произойдет. И в отладчике я вам всегда могу показать, что вот мол тут произойдет удаление обьекта. И оно произойдет. И деструктор класса вызовется именно в этот момент именно после этой строки.

[dotcom]

Мне верить не обязательно, просто почитайте про memory management для Objective-C.

Я так и не понял откуда у вас знания что на обьект нету ссылок в 20-и других местах, или например цикличных ссылок с которыми ARC не может справится. Как вам помогает retainCount? Как именно вы его используете? Вернул он число 5 в рантайме, и что дальше?

Вам же сверху написали про "прочитайте". Циклы, кстати, легко ловятся. А вот проблема с утеканием памяти асболютно такая же как и в JVM.

Ну и вопрос в сторону, у вас были реальные проблемы с паузами от джавовского GC?

Спросите на досуге ваших коллег незлой корпорации, почему Chrome для Андроида имеет свой менеджер памяти.

[Интеррапт]

А вот проблема с утеканием памяти асболютно такая же как и в JVM.

Только отлавливать и изолировать легче.

[adda_]

Я так и не понял откуда у вас знания что на обьект нету ссылок в 20-и других местах, или например цикличных ссылок с которыми ARC не может справится.

В смысле? Если я создаю обьект и манипулирую им, то я точно знаю, когда этот обьект будет реально удален из памяти. А вы, используя Джаву этого знать точно не можете. А есть ссылки на обьект или нет, я так точно всегда знаю. Например, передавая обьект какому-то методу там или задокументировано, что будет создан дополнительный рефернс на обьект или я всегда могу проверить опытным путем, изменился ли ref counter у этого обьекта. Вы забываете, что в Objective-C полностью ручная модель управления памятью, которая ничем от C++ не отличается (если брать C++ с подсчетом ссылок), кроме того, что в Objective-C были добавлены системы автоматизации подсчета ссылок (ARC). Давайте проведем исследование, вы напишите любой код на Objective-C, а я вам в точности расскажу когда такой-то обьект будет удален из памяти. Включая даже с описанием, когда autorelease pool удаляется и соответственно вместе с ним удаляются все переменные. А затем вы напишите код на Джаве и обьясните мне, когда конкретно ваш обьект удалится.
И самое главное, что в Objective-C это особо и не нужно, все что нужно знать, что если ты создал обьект, то тебе ему нужно будет сделать release (если речь идет о коде без ARC, т.к. ARC это делает автоматом, когда обьект выходит из области видимости). И что когда удалятся все обьекты, у которых есть ссылки на твой обьект, тот тут же произойдет освобождение памяти твоего обьекта. И это все очень легко прогнозируемо. Т.е. выходит обьект из области видимости - счетчик уменьшается на 1. Уменьшился до нуля, тут же удалился, а не ждет, чтобы gc это сделал. Что же тут сложного понять?

Насчет цикличных ссылок, так в Objective-C специально для этого есть weak properties и все отлично Objective-C с этим справляется, не выдумывайте. Да и даже до появления weak properties все вполне работало с assign property или с обнулением ссылок в десктрукторе класса. Проблема была в том, что некоторые делегаты обьявлялись как retain и тогда их нужно было обнулять в деструкторе класса. Этого уже давно нет, с появляением weak типа.

Ну и вопрос в сторону, у вас были реальные проблемы с паузами от джавовского GC?

В играх. В андроидовских. Вы думаете от хорошей жизни куча игровых движков на С++ под Андроид пишутся?

Дежавю. Это же Делфай, интерфейсед объекты.. Один в один.. Только на 15 лет раньше придумали.

[Интеррапт]

Дежавю. Это же Делфай, интерфейсед объекты.. Один в один.. Только на 15 лет раньше придумали.

Вы о чем конкретно? А то сам Objective-C как бы в 80-м году был создан. Ну а так да, Дельфи - продвинутый язык, кто бы сомневался.
(Кстати, если не сложно, чуть-чуть меньше оверквотинга).

[АццкоМото]

Дежавю. Это же Делфай, интерфейсед объекты.. Один в один.. Только на 15 лет раньше придумали.

Вы о чем конкретно? А то сам Objective-C как бы в 80-м году был создан.

А разве тогда в нем были эти фичи автоматического освобождения памяти? Я, конечно, не специалист в вопросе, но мне казалось, что это добавили много позже...

[Интеррапт]

Дежавю. Это же Делфай, интерфейсед объекты.. Один в один.. Только на 15 лет раньше придумали.

Вы о чем конкретно? А то сам Objective-C как бы в 80-м году был создан.

А разве тогда в нем были эти фичи автоматического освобождения памяти? Я, конечно, не специалист в вопросе, но мне казалось, что это добавили много позже...

А... нет. Это довольно новая вещь, я почему-то подумал именно о ref counting. Но я так понимаю, что ARC в Дельфи все-таки довольно лимитирован был, по сравнению с нынешним Objective-C, иначе не трубили бы сейчас такие победные реляции по поводу нового Дельфи компилятора:

http://www.monien.net/delphi-xe-4-is-arc-for-everyone/

As mentioned previously, Delphi XE4 will come with a new memory management, which is supposed to release us from hunting for memory leaks: ARC – Automatic Reference Counting.

...

ARC will only work with Delphi’s new compiler (a.k.a NextGen compiler) which currently exclusively targets the iOS platform. So you will see ARC at work only within the iOS Simulator and on actual iPhones/iPads and iPod touches. On Windows will still have to use the “classic” Delphi compiler, which doesn’t know about ARC.

[dotcom]

Дежавю. Это же Делфай, интерфейсед объекты.. Один в один.. Только на 15 лет раньше придумали.

Опять немного бесполезной тривии. Objective Pascal был отчасти "influenced by" Objective C много лет тому назад. Delphi, понятно, заимствовал синтаксис от Objective Pascal'я. Языки разные, конечно, но принцип легковесного ООП поверх процедурного языка остался.

[crypto5]

то все равно, оно будет уничтожено сразу же как LibIDN выйдет из области видимости.

С чего это? Вы же не знаете работает ли LibIDN с каким то глобальным кешем?

И ведь самое главное, что я могу breakpoint поставить на эту перменную и посмотреть ее reference count. Все на 100% детерминировано.

Я у вас уже спрашивал, откуда у вас уверенность что вы своим отладчиком сможете просмотреть все бренчи выполнения программы?
И еще один вопрос в сторону,как часто вы такое делаете?

[crypto5]

И к чему этот пример? Как я уже написал в этом случае джава с помощью escape analysis тоже с большой вероятностью выделит этот обьект на стеке и кильнет его при выходе из метода.

Escape analysis делает это для довольно простых случаев. А objective-c сделает это для любых случаев. Да и вот вы написали "с вероятностью", т.е. предугадать никогда не можете. А в случае с Objective-C я на 100% знаю, что произойдет с удалением обьекта и когда это произойдет. И в отладчике я вам всегда могу показать, что вот мол тут произойдет удаление обьекта. И оно произойдет. И деструктор класса вызовется именно в этот момент именно после этой строки.

Ну да, за счет оверхеда на подсчет ссылок.

[crypto5]

Мне верить не обязательно, просто почитайте про memory management для Objective-C.

Я так и не понял откуда у вас знания что на обьект нету ссылок в 20-и других местах, или например цикличных ссылок с которыми ARC не может справится. Как вам помогает retainCount? Как именно вы его используете? Вернул он число 5 в рантайме, и что дальше?

Вам же сверху написали про "прочитайте". Циклы, кстати, легко ловятся. А вот проблема с утеканием памяти асболютно такая же как и в JVM.

ARC не ловит циклические референцы, почитайте ка сами.

Ну и вопрос в сторону, у вас были реальные проблемы с паузами от джавовского GC?

Спросите на досуге ваших коллег незлой корпорации, почему Chrome для Андроида имеет свой менеджер памяти.

Давайте ка если вы уже сами "почитали" и "спросили", приводите более конкретные аргументы, чего вы хотели сказать. Я уже по вашему велению безрезультатно ходил и в гугл и в википедию.

[M. Ridcully]

ARC не ловит циклические референцы, почитайте ка сами.

А зачем их "ловить"? Из просто делать не надо. Один - strong. Остальные - weak.
И никакой ловли.