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

Вероятно, это наивный вопрос, но я все равно его спрошу.

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

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

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

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

Ответы

Ответ 1

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

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

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

Ответ 2

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

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

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

Bill Bumgarner написал удивительный набор статей об objc_msgSend()

Ответ 3

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

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

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

Ответ 4

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

В одном из таких сравнений производительности была создана игровая площадка:

  • Чистая версия C дала 60 кадров в секунду
  • Версия Objective-C дала 39 fps

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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