Escribiendo código limpio, rendimiento para el iPhone

Question

He estado desarrollando en el iPhone con Objective-C desde hace unos meses y he estado aplicando las mejores prácticas aprendidas y refinadas al desarrollar aplicaciones con Java. Estos incluyen: diseño de clases que tienen una responsabilidad única, aplicación de patrones de diseño cuando corresponda y escritura short methods que hacen una sola cosa. Para mí, estas prácticas son beneficiosas desde una perspectiva clean-code y son en gran parte independientes del dominio.

Estoy muy contento con los resultados. Sin embargo, algunos desarrolladores de iPhone me han aconsejado de forma independiente contra esto, ya que dicen que escribo demasiadas clases y demasiados métodos. En varios momentos se me ha advertido:

• La pila soplará
• Demasiados clases se ralentizará el iPhone hacia abajo (es decir, perceptible por el usuario)
• llamadas a métodos anidadas perjudicarán el rendimiento (es decir, perceptible por el usuario)

En la práctica no he tenido estos problemas. Si miro superficialmente a iPhone performance metrics, me parece que es poco probable que las llamadas al método extra y la sobrecarga del ciclo de vida del objeto para implementar patrones comunes y métodos cortos creen cualquier demora perceptible para el usuario. Sin embargo, el consejo de otros desarrolladores de iPhone me ha asustado un poco.

Me gustaría continuar aprendiendo y perfeccionando las prácticas de programación de dominio independiente que me han servido bien en el pasado, pero cuando desarrollo en el iPhone no deseo tomar una ruta que terminará en dolor.

Por lo tanto, con respecto a esta plataforma, ¿debería renunciar a algunas de las mejores prácticas comunes y ser más consciente de optimizar los gastos generales del ciclo de vida de llamadas y objetos del método? O debería continuar siguiendo Knuth's consejo:

optimización prematura es la raíz de todo mal (o al menos la mayor parte de ella) en programación

Answer 1

Para mí realmente se reduce a la capacidad de mantenimiento. con un código de buena calidad puede mantener el sistema mucho más fácil.

Tengo desarrolladores que trabajan conmigo y cuando sugiero que tomen atajos para hacer que un sistema funcione, me desprecian y entregan el proyecto tarde. y ha pagado a la larga todo el tiempo !!!

si se trata de una aplicación intensiva, que utiliza opebGL y el rendimiento no se puede convertir en un problema. si es solo una aplicación de datos o utilidad simple. recomendaría continuar con las mejores prácticas de código que conoces, y luego seguir aprendiendo, ya que son muy valiosas. La mayoría de los patrones son independientes del dominio y beneficiosos en todos los lenguajes de programación fundamentales.

Y si no explota la pila, vuelva a factorizar algunos de esos métodos/clases en llamadas individuales (al menos usted sabe que podría suceder y lo notará tan pronto como suceda). Y si no tiene, entonces tiene código para mantener que es fácil de leer por cualquier mono código a medio hornear que tiene que mirarlo más tarde.

Answer 2

Todo el problema con la desaceleración de las aplicaciones de OO es simplemente que el objeto puede salirse de control más fácilmente que los estilos de programación estructurados. Hubo un tiempo en que, antes de que las optimizaciones de las llamadas a los métodos mejoraran, esto podía marcar la diferencia, especialmente cuando se realizaban llamadas indirectas (es decir, virtuales).

Si sus objetos se usan mucho y tiene algunos objetos de nivel inferior a los que llama con frecuencia, entonces tal vez obtenga un rendimiento al usarlos, pero estoy hablando de millones de llamadas (he visto un código horrible en mi tiempo, tanto desestructurado, estructurado y OO!). También obtendrá más de un golpe de rendimiento si asigna y elimina lotes (LOTES) de objetos continuamente.

La única respuesta es, sin embargo, echar un vistazo. Si tiene un objeto que se asigna, se elimina rápidamente, luego se optimiza (incluso si se ve menos elegante), si tiene un objeto que llama sus métodos miles de veces, entonces optimícelo también. (¡pero una vez que hayas hecho esta medición, habrás medido su rendimiento y estarás refinando las partes lentas!)

Hay una compensación entre el código "elegante" y el código que funciona simple y rápidamente, don No vayas a ningún extremo y deberías estar bien.

Answer 3

Tuve una experiencia similar cuando desarrollé una aplicación Blackberry bastante complicada. A mí también se me dijo que evite las frecuentes asignaciones de objetos, las clases internas, etc. La aplicación original que teníamos era un desastre imposible de mantener. Recientemente reescribí la aplicación con un enfoque en el buen diseño de OO (patrones donde sea necesario, muchos objetos de propósito único y, a menudo, inmutables, etc.). En muchos lugares, violé el consejo de evitar ciertos constructos "costosos" y asignaciones de objetos. La aplicación resultante no solo era más fácil de mantener, sino que también era más pequeña. Si las asignaciones de objetos adicionales crearon gastos generales, ciertamente no me di cuenta. Creo que la lección aquí es exactamente lo que dijo Knuth. Enfóquese primero en un buen diseño, luego optimícelo si es necesario. Además, estos dispositivos móviles hoy en día tienen suficiente memoria para que este consejo caiga en desgracia ...

Answer 4

En general, no se preocupe. El único caso en el que usar objetos y mensajes podría ser un posible problema de rendimiento es cuando realiza cientos o miles de asignaciones a la vez o envía miles de mensajes cada pocos meses. No querrás usar objetos Obj-C para representar miles de vectores 3D en una simulación física.

Incluso en el caso de que esté haciendo muchos envíos de mensajes en un bucle, puede obtener un mejor rendimiento almacenando un puntero de función en el método apropiado antes del bucle.