что менее ресурсоемко: привязки, KVO или уведомления

Question

Вместо того, чтобы пытаться запустить кучу тестов. Кто-нибудь знает, что менее ресурсоемко?

Привязки, КВО или Уведомления? Кто-нибудь тоже проверял, чтобы увидеть?

Answer 1

Ответ Чака совершенно верен в отношении уведомлений против KVO, но я хотел бы остановиться на части «Привязки - это KVO + KVC + ...», которую он упомянул, потому что именно тамнастоящая боль в заднице может быть.Кодирование значения ключа, кажется, является более важным соображением, поскольку вы не можете использовать привязки без него.Если вы беспокоитесь о производительности по уважительным причинам, вам следует обратить внимание на то, что использование KVC может привести к значительным затратам.

Я бы сказал, что в любых обстоятельствах, требующих интенсивных запросов в результате одногодействие (пример: запрос нескольких тысяч объектов для получения результатов по нескольким ключевым путям каждый) будет показателем того, что вы можете избежать KVC (и привязок по расширению). Особенно с длинными путями ключей (-valueForKeyPath: vs. -valueForKey:).

Я сам столкнулся с этим и сейчас работаю над устранением этой части своей архитектуры какрезультат.Относительно небольшая стоимость кодирования значения ключа может серьезно возрасти, когда вы запрашиваете 16 000 объектов в результате полдюжины длинных путей нажатия клавиш в результате нажатия кнопки (даже с NSOperation / Queue).Разница между использованием KVC и старомодными вызовами [[object message] message ...] может означать разницу между несколькими секундами и более чем одной или двумя минутами на больших заданиях.Для меня тот же самый запрос, вызывающий методы доступа напрямую (например, [имя параметра] или [[имя переменной параметра]), представлял примерно 500% -ное увеличение скорости.Конечно, у меня довольно сложная модель данных с большим объемом данных для типичного документа.

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

В целом: если ваше приложение запрашивает / обновляет большие объемыданные, вы могли бы лучше избегать KVC и привязок для части запроса / обновления из-за KVC , а не из-за KVO .

Answer 2

На OS X это вообще не имеет значения.Они все легкие.Apple сама на это полагается, и поэтому реализации сильно оптимизированы.Я написал бы код так, чтобы он был как можно более читабельным, и оптимизировал бы скорость / потребление ресурсов только тогда, когда это необходимо.

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

Answer 3

По сути, это не совсем разные варианты. КВО - это особый случай уведомлений. Привязки KVO + KVC + пара классов клея.