×Закрыть

Objective-C [за что платим]

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

По ходу дела разбираюсь при помощи дизассемблера в том коде который генерирует ObjectiveC компилятор.

Может я не понимаю всей задумки «think different», но то что он генерирует немного пугает, на что тратятся вычислительные ресурсы.
Вот небольшой пример во что в конечном счёте превращается код написанный на ObjectiveC
Исходный код:

NSData *nameData = [NSData dataWithBytesNoCopy:attributes[0].data length:attributes[0].length freeWhenDone:NO];
NSString *name = [[NSString alloc] initWithData:nameData encoding:NSUTF8StringEncoding];

Что сгенерировал компилятор (поправил до компилируемого состояния):

long pool_NSData = objc_getClass("NSData");
NSData *nameData = (NSData*)objc_msgSend(pool_NSData, sel_registerName("dataWithBytesNoCopy:length:freeWhenDone:"), attributes[0].data, attributes[0].length, (BOOL)0);
long pool_NSString = objc_getClass("NSString");
long v0 = objc_msgSend(pool_NSString, sel_registerName("alloc"));
NSString *name = (NSString*)objc_msgSend(v0, sel_registerName("initWithData:encoding:"), nameData, NSUTF8StringEncoding);

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

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Это более чем нормально. Ты недооцениваешь возможности процессора и его слабые места. Несмотря на всю «гибкость» функционального програмирования, процессор — это КОНВЕЙР. Для него наиболее оптимальный код — это ЛИНЕЙНАЯ последовательность команд без ветвлений.

Так что на деле, если убрать многабукаф от компилятора, процессор увидит АДРЕС точки вызова и ничего кроме.

Нет, это именно динамическая диспетчеризация, т.е. адрес точки вызова ищется в процессе. А также объект может иметь метод, который сам поищет нужный метод где-то в другом месте (у делегата, например). Да, это медленнее, но благодаря этому можно взять стандартный контрол типа кнопки и без всяких наследований сказать ему «вот селектор такой-то у объекта, вызывай его».

Вы, собственно, почитайте историю того, почему в качестве ЯП под яблочные продукты был выбран Objective-C и что случилось с компанией Taligent в своё время.

P.S. К чести Эппл нужно отметить, что, как я слышал, вещи типа objc_msgSend у неё вылизаны до невозможности на уровне ассемблера и всех возможных оптимизацией.

Из этого кода непонятно на что тратятся ресуры.
Вот если бы возле каждой строчки был показан тайминг сколько эта строчка занимает,
а еще если бы была показана доля этой строки ко всему времени выполнения приложения,
тогда можно было бы судить о неэффективности рантайма.
А так все достаточно красиво, учитывая, что изначально Objective-C был препроцессором с таргетом в ANSI C.

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

Ну... вы много захотели, тайминги, замеры... отчёт в формате A4 :-) Я ведь специально в начале написал чем занимаюсь. С-код который приёл — компилируемый, если время есть лишнее можете и померять.
Ну а по поводу на что уходит время, ИМХО и так должно быть понятно. Как минимум это расчёт хешей (если не тупое сравнение строк в некоторых случаях типа

objc_getClass()
+ токенизация строк, разбор аргументов, построение карт и т.д.
Можно конечно попросить IDA пойти глубже и разобраться с подпольной кухней сего «чуда», но мне глубже не нужно.

Ну и что, что там сравнение ASCIIZ строки, последние Mac OS X и iOS от этого не страдают. Даже процессора в часах хватает. Ну, конечно, не эффективно, но люди и не на таком пишут.

В WinRT еще хуже, это все работает на CLR и через COM интерфейсы с нативными библиотеками. А в случае Android все тоже самое, только без COM и медленее в 2 раза.

Казалось бы — каким боком Android к топику %)

Ну-ка, а як інакше можна реалізувати особливості ObjC, позичені з смолтока?
Там же його синтаксис не для краси втулили ;-)

Итого, человек на N-ном месяце (а, может, и году) программирования на Objective-C открыл для себя фундаментальную основу вызова метода его объектов — динамическую диспетчеризацию.

Откуда таки суждения? Но вы экстрасенсорными способностями не обладаете.
Я до этого ни строчки не писал на ObjC.

Compared to other object-oriented languages based on C, Objective-C is very dynamic. The compiler preserves a great deal of information about the objects themselves for use at runtime. Decisions that otherwise might be made at compile time can be postponed until the program is running. Dynamism gives Objective-C programs unusual flexibility and power. For example, it yields two big benefits that are hard to get with other nominally object-oriented languages:

— Objective-C supports an open style of dynamic binding, a style that can accommodate a simple architecture for interactive user interfaces. Messages are not necessarily constrained by either the class of the receiver or even the method name, so a software framework can allow for user choices at runtime and permit developers freedom of expression in their design.

— Dynamism enables the construction of sophisticated development tools. An interface to the runtime system provides access to information about running applications, so it’s possible to develop tools that monitor, intervene, and reveal the underlying structure and activity of Objective-C applications.

developer.apple.com/...cles/ooWhy.html

Теперь понятно, спасибо.

Подписаться на комментарии