Consulta:
"Buenas a todos. Hace unos meses me comencé a meter de lleno con php. Después tuve que dejar otro tiempo más porque me surgieron proyectos en otras plataformas, y ahora estoy retomando para hacer un proyecto personal en php.
Me surgieron algunas dudas con respecto a la verdadera utilidad, en relación al rendimiento, de la programación orientada a objetos en php. Si bien no conozco como trabaja internamente php, es un lenguaje interpretado, es decir, que en cada carga o recarga de la página las clases en cuestión deben ser interpretadas una y otra vez.
¿Es más ineficiente interpretar una clase, que interpretar una secuencia de comandos? ¿Alguien conoce de esta interna?. En .Net las clases son compiladas una vez que fueron solicitadas, por lo tanto, con cargas o recargas posteriores solo resta usarlas tranquilamente, ya que sabemos que ya ha pasado por esa etapa previamente.
Solo me estoy enfocando en el rendimiento de la aplicación. Si lo analizamos desde otro punto de vista, de seguro que encontramos muchas más ventajas a la programación orientada a objetos que a la programación procedimental.
Espero que alguien me oriente un poco en esto."
El moderador y amigo GatorV le responde:
"Es mínimo el impacto, si a caso lo que es más es la memoria ram que llegue a consumir, aunque no es nada que impacte, ya que el compilador de PHP esta muy optimizado para evitar desperdiciar memoria.
Por otro lado si te importa un poco el tema de estar re-interpretando las clases, una vez que termines puedes usar Zend Optimizer para guardar solamente las clases en estado compilado, y asi eliminar el overhead de estar interpretando y ejecutando".
Mi respuesta (actualizada):
"Tus comentarios (completamente justificados) me hacen acordar a los mitos de la "optimización extrema" en PHP, algo que veo sí completamente injustificado.
La forma en que se hace las pruebas es generalmente muy fuera de la realidad, como hacer un loop de millones de registros para luego contar las milésimas de segundo entre usar un echo o un print.
El peor mal que podemos tener en la ingeniería de software es ir hacia la "optimización temprana" (varios [1], [2], [3], etc, sin descontar que el lenguaje PHP sigue evolucionando y siendo optimizado), es decir, preocuparnos tempranamente del rendimiento y no de la funcionalidad o el diseño de un sistema.
La parte que no se llega a entender es que ya pasamos la época de hacer páginas PHP embebidas con HTML y conexiones SQL, actualmente los proyectos requieren SISTEMAS, y estos poder escalar y desarrollar rápidamente de acuerdo a las necesidades del mercado.
¿Cuanto cuesta modificar un producto web que no es un sistema? ¿cuanto nos cuesta desarrollar funcionalidades nuevas?
Si no tienes diseño, si no aplicamos metodologías que incluyan POO, dudo seriamente que podamos estar aptos de desarrollar un sistema "medio" para arriba.
Pero eso de "no uses require_once porque es caro", "echo es más rápido que print" ó "print es más rápido que echo" (he visto artículos sobre "optimización extrema" que dicen lo contrario entre ellos), "usa ++$i en vez de $i++", etcétera, las considero completamente tontas e inútiles.
Podemos discutir que si tienes POO + Persistencia (BD), es seguro tendrás más consultas a la base de datos que si hicieras un JOIN y luego recuperaras los datos y procesaras, pero hay muchas técnicas para evitar esto, como el "lazy loading", evitando tener que consultar todas las veces por un mismo valor a la base de datos si ya lo tienes la primera vez, o evitar consultas SQL innecesarias por valores que perfectamente pueden estar en un array ya que no cambian (o en un archivo plano, luego lo puedes actualizar, etc), etc.
Siempre hay que tener en cuenta la escala del sistema, si es para 10 usuarios concurrentes, no me molestes con estas tonterías. ;-)
Pero puedes estar tranquilo, el problema no pasa por usar puramente POO, el problema para por otros lados, la latencia se estudia desde que el usuario ejecuta una acción y recorre todos los servicios y servidores hasta que el sistema responde, no es solo PHP.
PD: ahora me acuerdo que hace rato que quiero escribir un artículo sobre "lazy loading" ;-)
¿Tú qué opinas de la "optimización extrema"? ¿Crees en ella? ¿y de la "optimización temprana"? ¿te tomas el tiempo de verificar si realmente generan algún tipo de beneficios? ¿cómo optimizas tus sistemas? ¿cómo los diseñas?
9 comentarios:
Hola Enrique,
estoy totalmente de acuerdo en que centrarse en optimizar el rendimiento cambiando los prints por echos, etc... es un poco perder el tiempo.
El uso de la orientación a objetos reduce el rendimiento. No solo en PHP, en cualquier lenguaje. Sin embargo, es evidente que no se pueden construir grandes sistemas sin POO.
Para mí la clave está en no caer en la sobreingeniería (overengineering). Una de las críticas que se hacen al Zend_Form, por ejemplo, van en ese sentido. Se comenta que si utilizas un sistema de validators, filters, decorators, y form elements para algo tan "simple" como gestionar un formlario, el rendimiento se resiente y la cantidad de memoria necesaria para gestionarlo aumeta considerablemente.
Conclusión: orientar a objetos sí. Pensar en el rendimiento también. Y, como en casi todo, tratar de buscar un poco de equilibrio entre ambas cosas. Ni excederte en la optimización, ni excederte en la orientación a objetos...
Un saludo!
Como aspirantes a programadores seniors deberíamos de pensar en aplicaciones accesibles por más de 10 o quizás mas de 100 o 1000 usuarios concurrentes.
Últimamente se ven muchos ejemplos de páginas famosas al respecto FaceBook, Wikipedia, etc.
En este artículo de BarraPunto se comentan cosas así.
http://preguntas.barrapunto.com/article.pl?sid=08/12/11/0158221&from=rss
Hola Enrique,
Saludos y felicidades por PHP Senior en general, me parece muy buen punto de vista y análisis el que expresaste en este post, nunca antes me había presentando con la oportunidad de participar en tu blog, pero este tema es motivo de polémicas y dudas, siempre lo escuchamos que se tocan por todos lados incluso en mi caso en la universidad podemos escuchar críticas y puntos de vista acerca del uso extremo en optimización de sistemas, se da mucho en personas que tienen poca fe en la POO y mas si se trata de PHP, lo que si es cierto es cuanto mas complejo se vuelve un sistema no importa sobre en que este desarrollado siempre llegara a un punto en el que la programación estructurada no dará la talla para el problema.
Como todo en la vida antes de pensar que algo no es funcional siempre debemos analizar sus pro y contras para conocer si realmente es lo que necesitamos, en nuestro caso aplicado a los sistemas.
De igual forma como se comento muchas veces resulta poco funcional aplicar cosas complejas para operaciones sumamente sencillas, por lo que siempre debemos tener en cuenta esto como buenos programadores a la hora de aplicarlos a los problemas cuando participemos en proyectos del trabajo o personales sea el lenguaje que sea ;).
Un saludo a todos en PHP Senior.
Hace mucho, cuando las computadoras tenían un rendimiento limitado, la optimización era vital. De hecho, un buen programador sabía optimizar recursos para que la aplicación fuera lo mas rápida posible. Yo en los tiempos finales de mi vieja y querida Spectrum vi los juegos mas asombrosos que podía llegar a ver gracias a que los programadores le exprimían cada Kb y lograban cosas increíbles con las pobres capacidades gráficas con las que contaba esa maquinita.
Con el tiempo, las PC's tuvieron más y más potencia y los programadores se relajaron y así apareció el fatware. Ciertas aplicaciones entre una versión y otra con muy pocos cambios, de repente requerían una PC mucho mejor. Era inentendible.
Hoy, al programar en PHP no tomamos en cuenta un hecho concreto: corren sobre un servidor y además, sobre ese servidor pueden estar corriendo cien aplicaciones más.
¿Es bueno optimizar? Si el cambio o todos los cambios juntos son notorios me parece perfecto. Si uno se va a romper la cabeza optimizando para que la diferencia sea apenitas perceptible, no tiene sentido. Pero tengamos en cuenta que si podemos evitar comernos la memoria del servidor, debemos hacerlo.
Creo también que los programadores están cada vez mas perezosos porque todos temen "reinventar la rueda", pero si Google y Yahoo no la hubieran reinventado, todavía seguiríamos buscando en el Altavista.
Los frameworks en su mayoría son prácticamente vampiros chuparecursos de los servidores en favor de la pereza del programador que quiere trabajar lo menos posible.
Es mi punto de vista. Saludos a todos.
Este es el problema de la gente que no sabe nada de adminsitracion de servidores. Si supieras algo de linux o de C sabrias que esto si afecta a la larga y obviamente no a paginas o sistemas internos que tienen poca carga, pero a gran nivel, como un portal estas optimizaciones pueden ser claves.
Estimado Jhony:
> Este es el problema de la
> gente que no sabe nada de
> adminsitracion de servidores.
[...]
No sé si haces referencia al post o sobre alguno de los comentarios, pero en lo personal sí tengo bastante experiencia en servidores GNU/Linux y una cosa no quita a la otra.
Por eso hablo de "latencia" de todo el sistema, además, el punto central es el título del post: "Rendimiento: ¿conviene utilizar POO?"
PD: tal vez no te entendí y no te referías al contenido del post.
Hola Enrique,
Pues estoy completamente de acuerdo en lo que comentas, aunque creo que la cuestión debería ser más bien: "Rendimiento, ¿conviene usar php?", ahí tenemos algunos ejemplos como el de Facebook que no da más de sí y que está completamente saturado.
Todos coincidimos en que la POO es lenta y consume recursos, pero las aplicaciones web de hoy en día son cada vez más complejas y con más funcionalidades, amén de necesitar continuos retoques y evoluciones, por lo que considero un suicidio desarrollar algo decente sin POO, salvo que sea un servicio crítico enfocado a rendimiento, y en esos casos, podemos simplemente programar la parte crítica de forma estructurada para maximizar el rendimiento, como hemos hecho toda la vida.
Seamos sinceros, ¿cuantos hemos programado o vamos a programar aplicaciones con cientos de miles de accesos al día?, probablemente pocos por no decir ninguno, ¿de qué sirve super optimizar nuestro código hasta niveles insospechados si nadie va a acceder?, y no me digan que consume mucha memoria porque si no accede nadie, no consume nada, ¿no será mejor invertir ese tiempo en hacer nuestro código más simple, sencillo y reusable?.
@A.M.: Respeto tu punto de vista. Además soy perfectamente consciente de que los recursos son limitados y no hay que malgastarlos, pero de ahí a que llames vagos a los programadores que usan frameworks me parece demasiado osado, principalmente porque hay muchos tipos de frameworks (yo he usado 4 diferentes ya, uno de ellos programado por mi) y no todos funcionan igual, de hecho, en el caso del Zend Framework nisiquiera estas obligado a seguir el patrón MVC, por lo que el rendimiento mejoraría bastante.
Además, muchos trabajamos con varios proyectos de forma simultanea (y también damos soporte), ¿te imaginas lo que puede ser eso sin seguir la misma estructura para todo y sin poder reutilizar codigo?. No me quiero ni imaginar lo que tiene que ser tener que hacer una interfaz de administración desde 0, sin poder aprovechar los objetos que ya tenemos creados.
Bueno, para resumir, para rendimiento, no conviene la POO, ni PHP, ni Apache.
Saludos.
Hola,
Enhorabuena por el blog.
Me gustaría recordar la Ley de Amdahl, que dice cuál es el máximo incremento del rendimiento en un sistema si optimizamos una parte determinada del mismo.
Cuando diseñamos aplicaciones deberíamos tener en cuenta el rendimiento de forma muy global para centrarnos más en la funcionalidad y la seguridad del sistema. Después será más fácil decidir si merece la pena optimizar una parte determinada o sacrificar la capacidad de mantener código o incluso rediseñar un módulo en pro del rendimiento.
Un saludo,
www.treeweb.es
Publicar un comentario