Costo del envío de mensajes en Objective-C

Question

Tengo curiosidad por saber el costo del envío de mensajes en Objective-C en diversas situaciones. Particularmente, quiero guiar mi elección del diseño del programa, por lo que no me siento tentado a optimizar prematuramente al evitar el envío de mensajes cuando se trata de un mejor diseño.

Un caso en mi proyecto actual es que tengo una clase con variables de instancia: offsetX y offsetY. A menudo quieren compensar el absoluto y por el momento no tengo esta línea de código por todo el lugar: -

int absOffset = ((offsetX < 0.0) ? -offsetX : offsetX) + 
       ((offsetY < 0.0) ? -offsetY : offsetY); 

Ahora bien, si esto era C++ crearía una función en línea que devuelve el valor de absOffset. Incluso en Java/C# podría definir una función como final/sellada y estar bastante seguro de que estaría en línea.

El objetivo-C sería la siguiente: -

-(int)absOffset { 
    return ((offsetX < 0.0) ? -offsetX : offsetX) + 
      ((offsetY < 0.0) ? -offsetY : offsetY); 
} 

y yo lo llamaría así: -

int ao = [self absOffset]; 

Ahora, es el compilador capaz de línea que? Supongo que es capaz, al menos, de corregirlo en una llamada a función directa y evitar el envío de mensajes dinámicos que (supongo) objetivo-c debe usar debido a su tipo de sistema.

Además, en general, ¿cuánto cuesta el envío de mensajes en el objetivo C? ¿Difiere al llamar a través de un 'id' frente a un puntero a una clase concreta?

Answer 1

Objective C messages are very fast. La velocidad es comparable a las llamadas a métodos virtuales en C++, aunque no tan rápido. Evitar la transmisión de mensajes es definitivamente optimización prematura. Puede que no quieras hacer mucho en un bucle interno, pero los algoritmos que elijas y otros factores tendrán un factor mucho más grande en la rapidez de tu código. Si es demasiado lento, use un generador de perfiles y vaya desde allí.

Answer 2

Primero, usaría la función C, fabs() para esto. Para otras cosas, escribir funciones simples, en línea, C para pequeños casos auxiliares puede funcionar bien. Usar métodos de conveniencia más que un comportamiento discreto puede ser un signo de mal diseño. El rendimiento ni siquiera llega a eso.

A continuación, el compilador no puede optimizar una llamada de método. Es un lenguaje dinámico, la llamada no se resuelve hasta el tiempo de ejecución. Varias técnicas de Objective-C podrían vencer cualquier intento del compilador de hacerlo.

No hay diferencia en el tiempo de ejecución entre llamar a un método en un "id" frente a un puntero tipeado: pasan exactamente por el mismo mecanismo.

Finalmente, si está pensando en las características de rendimiento antes de medir, ya está optimizando prematuramente. Eso no quiere decir que es nunca apropiado, como algunos pueden hacer creer, pero por lo general es cierto. En este caso, creo que si pones el diseño primero, probablemente termines con un perfil de rendimiento lo suficientemente bueno. Mida y optimice más tarde, según sea necesario.