¿Dónde cae Objective-C en el continuo de rendimiento del lenguaje?


20

Parece que se discute mucho sobre los diversos méritos de velocidad para C o C ++ en comparación con Java o Python, pero rara vez veo mencionado Objective-C. Aproximadamente, ¿dónde cae en términos de rendimiento del lenguaje?


23
1986 - Brad Cox y Tom Love crean Objective-C, anunciando que "este lenguaje tiene toda la seguridad de memoria de C combinada con toda la velocidad vertiginosa de Smalltalk". Los historiadores modernos sospechan que los dos eran disléxicos. ( fuente )
Mason Wheeler

44
Cae en el rango donde el rendimiento no importa mucho. Es el único lenguaje compatible para interactuar con Cocoa, por lo que si desea hacer eso, nada más funciona en absoluto. Para cualquier otra cosa, lo consideraría una elección terrible, independientemente del rendimiento.
Jerry Coffin

1
El "rendimiento" no es una característica de un lenguaje, sino de una implementación del lenguaje y, lo que es más importante, de los programas escritos en ese idioma. Puede escribir programas muy rápidos en Objective-C, o puede escribir programas muy lentos.
Caleb

No tiene una sintaxis horrible, pero no es un lenguaje de bajo rendimiento basado en sus compiladores actuales, ya que el rendimiento se basa más en el compilador / vm que en el lenguaje real.
Plataforma

Respuestas:


28

A diferencia de C ++, Objective-C está diseñado como un superconjunto limpio de C. Los pocos compiladores de Objective-C que he usado son mejor conocidos como compiladores de C, pero también manejan Objective-C.

Por lo tanto, es seguro asumir que en el nivel de generación de código, C y Objective-C son equivalentes.

La primera diferencia aparece en el OOP ABI, también llamado "enlace de método tardío". Al igual que en C ++, Objective-C se basa en tablas de puntero de función generadas por el compilador que se recorren en tiempo de ejecución.

Sin embargo, a diferencia de C ++, el método de enlace es más "dinámico" y promueve el uso de la idsuperclase en todas partes, por lo que en teoría es un poco más lento que C ++. En la práctica, esta diferencia es muy inferior a la mensurable.

Finalmente, el problema de rendimiento más importante es la calidad de las bibliotecas utilizadas. Dado que Objective-C solo es muy popular en los sistemas Apple, es razonable suponer que lo está utilizando con Cocoa; que es un buen conjunto de bibliotecas de alto nivel. En la mayoría de los casos, puede dejar el trabajo pesado a ellos, por lo que su código no tiene que ser tan rápido o si hace una gran carga, entonces es probable que sea una base de código mayormente estática, más o menos similar a la simple C .

TL; DR: está ahí con los lenguajes C y C ++ donde más importa. Si no está obteniendo un buen rendimiento, verifique sus algoritmos; como en cualquier lenguaje serio.


44
De hecho, el objetivo moderno c es casi tan supersticioso como el C ++ moderno. En C se le permite hacer aritmética en punteros arbitrarios, no se puede en ObjC. Además, la diferencia de rendimiento debido a la búsqueda de métodos es medible: la ruta rápida de objc_msgSend es aproximadamente cuatro veces más pesada que una llamada a función miembro (y las rutas lentas no son tan rápidas como la ruta rápida).

11

Objective-C es más lento que C / C ++. La razón es el tiempo de ejecución de Objective-C que distribuye búsquedas de métodos dinámicamente en tiempo de ejecución de la misma manera que Smalltalk, del cual se ha hecho cargo de este modelo de ejecución. El envío de todos los métodos en tiempo de ejecución se denomina "envíos de mensajes verdaderos" en lugar de llamada de función en C / C ++, donde la dirección de la función se determina en tiempo de compilación (excepto los métodos virtuales de C ++). Pero no puedo decir cuánto más lento es Objective-C. ASAIK solo se usa para el desarrollo de aplicaciones debido a la penalización de rendimiento.


1
Encontré esta comparación de rendimiento con C: rmarcus.info/?p=488 Parece que Objective-C está, sin embargo, bastante cerca de C.
OlliP

Sería bueno comparar el Objetivo C con el resto del paquete en el Juego de Benchmarks
Deer Hunter

Creo que la comparación de rendimiento debe tomarse con algo de sal ya que el código Objective-C es en cierta medida el código C y no el envío de mensajes Objecttive-C. No sé para qué es la rebaja. Desarrollé Smalltalk durante más de una década y Objective-C se basa en Smalltalk de muchas maneras. Creo saber de qué estaba hablando.
OlliP

No el downvoter; Estoy principalmente interesado en algoritmos muy numéricos, el despacho dinámico no importa mucho dentro de ellos.
Deer Hunter

8

Respuesta corta: está compilada en un formato similar a C / C ++ / D / Go / Rust. No utiliza un entorno virtual como Java / .Net. Y no se interpreta como Python / Ruby / Lua / JavaScript. Por lo tanto, está en el extremo más rápido del espectro.


7

Las diferencias de velocidad fundamentales entre Obj-C y C / C ++, como Oliver dice a continuación, se deben al envío de métodos dinámicos.

Este artículo describe estos gastos generales en Obj-C http://it.toolbox.com/blogs/macsploitation/bypassing-objectivecs-message-passing-mechanism-for-speed-24946

También proporciona un truco muy bueno para optimizar su código Obj-C cuando determina que el envío del método (es decir, objc_msgSend) es el factor limitante: obtenga un puntero a la función una vez y úsela para llamarla muchas veces. No debería ayudar demasiado ya que los tiempos de ejecución Obj-C hacen esta optimización automáticamente .

Tenga en cuenta que el costo real del despacho del método dinámico se debe a errores de caché, ya que rompe la predicción de la rama de la CPU. Estos son difíciles de perfilar y puede ser que el código citado anteriormente no mida el costo real de la pérdida de caché.

Una discusión más útil está aquí: http://www.cocoabuilder.com/archive/cocoa/106535-instance-variable-access.html#106605

En pocas palabras: las mayores diferencias entre los idiomas son sus algoritmos. Más allá de eso, existe una diferencia de velocidad fundamental entre Obj-C, C y C ++, debido al envío de métodos dinámicos o virtuales. Este segundo punto no parece ser grande. Y el artículo anterior ofrece un truco para optimizarlo, si puede encontrar puntos calientes a través de la creación de perfiles, lo que puede ser difícil debido a la falta de memoria caché de la CPU.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.