Должен ли я использовать сборку мусора Objective-C при записи для 10.5+?

При написании довольно типичного кода Mac в среде OS X 10.5+, каковы недостатки использования сборки мусора?

Пока что все остальное, что я написал, было либо 10.4-совместимым, либо на iPhone, так что мне стало довольно удобно с сохранением / выпуском, но теперь, когда я работаю над большим проектом, который только 10.5, мне интересно, есть ли Есть ли какие-то минусы в том, чтобы просто идти вперед и использовать сборщик мусора Objective-C 2.0.

Что вы думаете, ребята?

10.12.2008 17:44:21
4 ОТВЕТА
РЕШЕНИЕ

Если вы пишете новый код Какао и нацелены на Mac OS X 10.5, используйте сборку мусора Objective-C.

Если вы пишете какой-то код, который также может потребоваться для запуска на iPhone, вы можете очень легко написать и протестировать этот код для обеих моделей, сохранив этот код в отдельной инфраструктуре, написав его со свойством -retainи -releaseиспользованием, а также настроив как свою инфраструктуру, так и ваш тестовый модуль для него поддерживается GC, а не только GC .

Xcode запустит ваш пакет модульных тестов дважды, один раз с включенным GC и один раз с выключенным GC, и ваш фреймворк будет использоваться в обеих моделях исполнения. Затем, если вы в конечном итоге захотите перенести этот код уровня модели на iPhone, вы можете поместить его в статическую библиотеку, предназначенную для iPhone, или включить ее непосредственно в проект iPhone.

Независимо от того, рассматриваете ли вы запуск своего кода на iPhone, вы должны определенно ориентироваться на сборку мусора, если вашему приложению потребуется Leopard. Это облегчит разработку, и сборщик мусора в Objective-C будет работать достаточно хорошо.

12
11.12.2008 10:28:07

Если есть возможность портировать ваше приложение на iPhone, вы не должны его использовать.

Сборка мусора может оказать негативное влияние на производительность, если у вас есть особые случаи использования. Без GC у вас есть точный контроль над уничтожением объекта, что не так в мире GC. В большинстве проектов стоит включить GC, так как он менее подвержен ошибкам и проще.

В теории , управление памятью без GC всегда может быть быстрее, чем с GC, однако, это не так , в большинстве практических приложений (с GC, как правило , более оптимизировано , что человеческое существо).

2
10.12.2008 18:01:13
В теории GC может быть быстрее! Это тот случай, когда системе не нужно освобождать память, прежде чем ваша программа завершит работу - тогда вы получите более быстрое выделение (просто следующий кусок из кучи) и никогда не тратите время на освобождение памяти.
Kornel 11.12.2008 10:37:44
Да, конечно. Но теоретически вы всегда можете написать GC, который управляет вашей памятью в среде без GC. ;)
Mehrdad Afshari 11.12.2008 10:39:57
нет, GC не может восстановить память как система без GC. Он никогда не знает, когда вернуть, пока не сделает сбор. Возможна комбинация обоих: выделения из кучи и освобождения, когда он выходит из области видимости (аналогично использованию конструкций ()), но без использования «чистого» GC.
gbjbaanb 28.12.2008 21:23:11
Ваш комментарий просто не соответствует действительности. Автоматический сбор работает лучше, чем ручной сбор во многих случаях. (Поскольку коллекция сгруппирована в одну операцию, а не выполняется по
jrockway 17.10.2009 05:06:20
Большая часть снижения производительности в программах GC обусловлена ​​более высокими требованиями к памяти. Чем больше используемой памяти, тем больше кеш-памяти и они очень дорогие. Также программы GC обычно написаны не очень оптимизированными для повторного использования памяти. Но это проблема программистов, ставших ленивыми и технически не связанными с GC.
Lothar 30.07.2012 00:18:59

Я предпочитаю заниматься управлением памятью сам, просто потому что мне нравится иметь этот уровень контроля. Из опыта других языков (C #) я знаю, что GC не позволяет вам полностью игнорировать проблемы с памятью, и то же самое в Какао с такими вещами, как слабые ссылки и обратные вызовы, использующие (void *), когда объект явно не принадлежит другим объектом. Вы в основном меняете один набор проблем (утечки памяти) на другой. Лично я не склонен делать слишком много ошибок управления памятью в наши дни, и те, которые я делаю, довольно легко отследить.

В некоторых ситуациях (например, при реализации методов источника данных для NSOutlineView, когда вы не хотите сохранять объект, предоставляемый в виде структуры), где я думал, что GC будет действительно полезен, но я не сделал ничего реальных испытаний с ним пока нет.

Apple перечисляет некоторые другие преимущества и недостатки в руководстве по программированию GC .

2
10.12.2008 18:02:18
Он не делает это, чтобы оптимизировать.
mk12 15.11.2009 22:30:10
Разве вы не хотите сказать, "игнорировать проблемы с памятью, а это не то же самое в Какао"?
Dan Rosenstark 12.05.2010 22:01:05

GC устарела, начиная с 10.8. На самом деле никогда не было хорошей идеей принять эту технологию, если не считать черлидинга, потому что цели производительности и стабильности никогда не были достигнуты.

Управлять памятью «вручную» на самом деле очень просто, потому что код управления в значительной степени может быть разложен. Моя база кода имеет <1% кода, связанного с управлением памятью, и это больше, чем нужно. Так что я также скептически отношусь к ARC, просто потому, что проблема, которую он решает, настолько мала, что даже довольно небольшие проблемы с технологией делают ее менее чем стоящей.

-1
12.12.2012 15:33:28
Это не правда, что это никогда не было хорошей идеей. Обе технологии имеют одну и ту же цель; большая часть кода, написанного для обоих, выглядит одинаково, и они концептуально эквивалентны, когда речь идет о том, чтобы присваивать назначение как владение. Рассматривать процент кода управления памятью как доказательство его простоты очень неточно. Конечно, с ростом процента вероятность ошибки возрастает, но для введения серьезной ошибки управления памятью требуется всего одна строка (или одна пропущенная строка).
user155959 28.02.2013 17:22:00
Наличие хороших целей не делает что-то хорошей идеей, дорога в ад вымощена благими намерениями и все такое. GC просто никогда не работал должным образом, поэтому принятие его никогда не было хорошей идеей. Обосновывая ARC, Крис Латтнер описал недостатки GC: lists.apple.com/archives/objc-language/2011/Jun/msg00013.html Эти недостатки присутствовали всегда, они не просто внезапно появлялись после появления ARC. Это место слишком короткое для доказательств, но тот же аргумент, который вы применяете к управлению памятью, применим и ко всему остальному коду, поэтому ваш аргумент является ложным.
mpw 14.09.2013 15:16:00
Недостатки GC были задокументированы; это никогда не было под вопросом. Общее количество строк кода сохранения / освобождения не имеет значения в качестве аргумента в пользу ручного управления памятью, поскольку для появления ошибки требуется всего один цикл сохранения или другая случайная ошибка. Иногда мы привязываемся к чему-то из-за времени, которое мы вложили в это, и мы начинаем не доверять новым вещам. Я считаю, что противостоящий идиоматическому современному Objective-C, который использует ARC, стоит на неправильной стороне истории по неправильным причинам.
user155959 2.12.2013 17:52:13