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?
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?
Respuestas:
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
id
superclase 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.
fuente
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.
fuente
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.
fuente
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.
fuente