Разница в использовании памяти b/w Конфигурация отладки и освобождения

Question

Я использую taskInfo, чтобы получить объем памяти, который использует мое приложение программно. Код, который в основном

kern_return_t result = task_info(mach_task_self(), TASK_BASIC_INFO, (task_info_t)&info, &num); 
    if (result == KERN_SUCCESS) { 
     memoryUsed = (double)(info.resident_size/1000000.0); 

Когда я запускаю мое приложение на Debug конфигурации он сообщает гораздо больше памяти используется, по сравнению с тем, когда я запускаю его на Distribution (~ 100MB разницы). Поскольку есть некоторые другие сторонние библиотеки, которые связаны, я не уверен, что они делают некоторые странные вещи.

Мой вопрос предполагает, что мое приложение не делает ничего странного, так это нормально иметь такую ​​огромную разницу?

P.S. : Я также использую cocos2d, но я думаю, что это довольно безопасно.

Answer 1

После того, как я поработал с ним еще некоторое время, я обнаружил, что никаких проблем с cocos2d или каких-либо других фреймворков нет.

Вместо этого был волосатый кусок кода, который делает что-то вроде

dispatch_async(dispatch_get_global_queue(DEFAULT, 0), ^{ 
    for(int i = 0; i < 100000; i++) { // a big loop 
     [a.b doSomethingAtIndex:i]; 
    } 
}); 

Объект a был реализован в качестве прокси-объекта и используется forwardInvocation: для разрешения вызова сообщение a.b поэтому эти вызовы были выделены, но никогда не удаляется так как он не был окружен ни одним @autorelease pool.

Answer 2

ARC чувствителен к настройкам оптимизации компилятора.

Конфигурация отладки по умолчанию приложения отключает оптимизацию (-O0). Это заставляет ARC быть педантичным (избыточным?) В retain s и autorelease s его вставками, которые, в свою очередь, могут увеличить время жизни объектов, превышающих ожидаемые.

С другой стороны, конфигурация выпуска по умолчанию включает оптимизацию (-Os). Это приводит к тому, что некоторые модели retain/release будут оптимизированы (я думаю, что это также делает менее частое использование autorelease?), Который заканчивается dealloc ранее объектом, что означает, что у вас будет меньше их висящих вокруг.

Попробуйте это: перейдите к настройкам сборки и измените «уровень оптимизации» конфигурации отладки в разделе «Генерация кода». Посмотрите, если вы все еще видите больше памяти, используемой после этого.

Answer 3

Я бы сказал, что это ожидаемое поведение. По крайней мере, это всегда было во всех проектах, где я сравнивал использование памяти между сборками DEBUG и RELEASE.

Одна из причин, очевидно, заключается в том, что DEBUG строит намного больше вещей, которые делаются и, возможно, хранятся в памяти. Отладочный материал в основном, ваш и фреймворк (т.е. cocos2d). Различные утверждения и журналы добавят больше (временного) использования памяти. Связанные службы отладки и отладки могут также потреблять дополнительную память, которая приписывается приложению.

Не о чем беспокоиться. Измерить использование памяти только в сборках релизов, потому что это то, что в конечном итоге будет работать на устройствах пользователей.