Особенности штрафов за производительность в Objective-C

Question

Я экспериментировал с использованием Objective-C (в частности, среды выполнения GNU, я не использую GNUStep или что-то подобное) для расширения C объектами. Пока все идет хорошо - он работает хорошо, и мне очень нравится синтаксис, однако из того, что я читал, есть снижение производительности при использовании объектов Objective-C.

Обычно я не склонен к преждевременной оптимизации, но я разрабатываю игру, и поэтому производительность в конечном итоге окажется довольно критичной - я хотел бы знать, во что я ввязываюсь! Несколько человек предположили, что я буду в порядке, используя Objective-C в игре, если мои самые внутренние циклы написаны на стандартном C, однако вопрос заключается в том, чтобы найти точку, где я должен сделать это переключение.

Итак, мой вопрос состоит из двух частей:

• Что именно повлечет за собой снижение производительности? (поэтому я знаю, чего мне следует избегать)
• Примерно Насколько значительным является это снижение производительности? (так что я могу заранее угадать, какие части моей игры нужно будет написать на С в любом случае)

Я предполагаю, что вызов методов для объекта Objective-C повлечет за собой наказание, но я не был уверен, что еще будет - вызовет ли удаление ссылки на объект Objective-C такой же штраф?

int a = myobj->a;

Как насчет использования try-catch-finally - повлечет ли это снижение производительности в ситуациях, когда нет исключений?

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

В данный момент меня не интересует C ++, я просто экспериментирую с Objective-C.

Answer 1

Итак, мой вопрос двоякий:

Что именно повлечет за собой снижение производительности? (поэтому я знаю, чего мне следует избегать)

Насколько значительным является это снижение производительности? (так что я могу заранее угадать, какие части моей игры нужно будет написать на С в любом случае)

(моя база из реализаций Apple:)

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

стоимость этого звонка / сообщения примерно в 4 раза выше стоимости виртуального звонка на c ++.

эти вызовы не могут быть оптимизированы (если кто-то не делает хорошую реализацию для JIT / HotSpot), и методы, в отличие от c или c ++, могут не быть встроенными.

но это не просто обмен сообщениями:

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

objc_msgSend и варианты (основа реализации обмена сообщениями во время выполнения) могут занимать, например, 10% только времени выполнения (крайние случаи реального мира).

это может также добавить к двоичному размеру.

Идиоматическое использование толкает его дальше от скорости c ++ или c во многих областях. (например, рассмотрите, как числа передаются / обрабатываются).

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

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

int a = myobj-> a;

без различия по сравнению с с

... исключения ...

(iirc) В предыдущей модели исключений Apple использовалась дорогостоящая настройка, теперь они соответствуют принципам нулевых затрат в c ++ (оптимизировано так, что исключения не будут генерироваться регулярно, и они минимальны при вводе / настройке, но дорогие для выброса / отлова ).

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

Answer 2

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

Другими словами, вы могли бы получить ответы, в которых говорилось бы, что то или иное является «эффективным» или «неэффективным», но применимо ли это в вашем случае к полной WAG. Поэтому нужно попробовать, и сама программа скажет вам, какие части нуждаются в чем-то лучшем.