Objective-C против скорости C

Question

Это, наверное, наивный вопрос, но я все равно его задам.

Я работаю с Core Audio (C API) на iOS и смешиваю C с Objective-C. У моего класса есть расширение .mm, и пока все работает.

Я читал в разных местах о том, что Objective-C работает медленно (без подробной информации - и я не заявляю, что это так). Я понимаю, что не нужно вызывать Objective-C из-за обратного вызова Core Audio и т. Д., И о причинах этого.

С другой стороны, мне нужно вызвать класс, который обрабатывает материал Core Audio из моего GUI, чтобы внести различные изменения во время выполнения. Будет происходить обход массивов, в основном, смещение данных, используемых Core Audio. Будет ли какая-то выгода от скорости написания моих функций на C и сохранения моих переменных, скажем, в векторах, а не в NSMutableArrays?

Я работаю с Objective-C / iOS всего несколько месяцев, поэтому у меня нет никакого взгляда на это.

Answer 1

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

Однако, что более важно, вы оптимизируете преждевременно.Существует ОЧЕНЬ высокая вероятность того, что дополнительные накладные расходы Objective-C не окажут заметного влияния на производительность вашего приложения.

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

Answer 2

Основной удар по производительности с Objective-C заключается в работе, необходимой для отправки вызова метода. Objective-C является динамически связанным, что означает, что объект, получающий сообщение (селектор), решает, что с ним делать во время выполнения. Это реализовано с помощью хеш-таблицы. Селектор хешируется (я думаю, что во время компиляции) и сопоставляется с методом, который вызывается через хеш-таблицу, и для поиска требуется время.

Сказав это, поиск метода - который происходит в objc_msgSend() очень оптимизирован. Фактически, это ручная работа на ассемблере. Я слышал, что по сравнению с вызовом функции C издержки составляют около 20 машинных инструкций. Как правило, это не имеет большого значения, но если вы пробегаете элемент 100 000 NSArray, поиск каждого элемента с -objectAtIndex: становится довольно трудоемким.

Однако почти в каждом случае дополнительная гибкость и функциональность оправдывают затраты. Вот почему ответ от wadersworld содержит хороший совет.

Билл Бумгарнер написал потрясающий набор статей об objc_msgSend ()

Answer 3

В то время как другие ответы дали количественную оценку того, что диспетчеризация динамического метода (objc_msgSend), будучи вручную настроенной сборкой, добавляет около 20 машинных инструкций, существует еще одна возможная причина более низкой производительности в Objective-C по сравнению с C: Objective-C имеет более богатыеФонд библиотеки.

У одного такого сравнения производительности была игра, генерирующая ландшафт, следующим образом:

• Чистая версия C давала 60 к / с
• Версия объективной C давала 39 к / с

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

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

Answer 4

Медленный относительный.

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

Для обработки необработанных сэмплов Core Audio придерживайтесь использования C. Для обработки событий Core Audio, связанных с пользовательским интерфейсом (остановка, запуск, свойства и т. Д.), Их инкапсуляция в Objective C не будет иметь никакой измеримой разницы в скорости. *

Answer 5

Objective-C не медленный, это буквально C с объектами.

Класс в Objective-C состоит из нескольких разных вещей:

• Карта селекторов для функций (реализация методов)
• Карта имен для типов (переменных экземпляра)
• Карта имен для типов и функций (свойств)

Итак, Objective-C будет примерно таким же быстрым, как и сам вызов необработанных функций C, с небольшими затратами на поиск функции.

Answer 6

Все зависит от того, что вы делаете. В любом случае, используя основной звук, 99% вашего времени исполнения должно быть потрачено на библиотечные функции. Теперь, если вы делаете что-то глупое - возьмите вторую семпл сэмплов, превратите каждый в NSNumber, сохраните их в NSMutableArray и сделайте рукописное БПФ с вызовами [[myArray objectAtIndex: i] doubleValue], вы получите то, что вы заслуживаете , Самый медленный iPhone может делать довольно много вызовов методов в микросекунду.

Независимо от того, используете ли вы функцию C или метод Objective-C, не имеет значения. Разница лишь в том, сколько методов Objective-C вы вызываете. Множество крошечных методов Objective-C, вызываемых миллион раз, - это большие издержки. И нет закона, запрещающего использование массивов C в коде Objective-C.

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

Answer 7

цель c быстрая, как c , потому что нет компилятора Objective C, и весь код цели C разрешается до C с использованием структур и указателей на функции.Цель C - это способ, которым мы можем писать объектно-ориентированное программирование на C. Все возможности объектно-ориентированного языка программирования (Small Talk в цели C) создаются с использованием C. На самом деле мы можем определить объект в C с помощью структур (canпеременные экземпляра класса) и связанные с ними функции, управляющие этими данными.Передача сообщений или вызов функции объекта осуществляется с помощью функции

objc_msgSend(receiver,selector,arg1,arg2....)

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