orientada - ¿Es lento el PHP orientado a objetos?

php orientado a objetos pdf (11)

Aquí está un buen artículo que discute el problema. También he visto algunos puntos de referencia anecdóticos que pondrían la sobrecarga de OOP PHP en un 10-15%. Personalmente, creo que OOP es una mejor opción, ya que al final puede funcionar mejor solo porque probablemente fue mejor diseñado y pensado. El código de procedimiento tiende a ser complicado y difícil de mantener. Al final, debe ser lo importante que es la diferencia de rendimiento para su aplicación en comparación con la capacidad para mantener, extender y simplemente comprender.

Solía usar PHP de estilo de procedimiento. Más tarde, solía crear algunas clases. Más tarde, aprendí Zend Framework y comencé a programar en estilo OOP. Ahora mis programas se basan en mi propio marco (con elementos de cms, pero sin ningún diseño en el marco), que se basa en la parte superior del marco de Zend.

Ahora consta de muchas clases. Pero cuanto más programa, más me temo. Me temo que mi programa será lento debido a que tengo miedo de agregar cada clase que pueda ayudarme a desarrollar pero puede ralentizar la aplicación.

Todo lo que sé es que incluir una gran cantidad de archivos ralentiza la aplicación (si utilizo eAccelerator +, ¡reunir todo el código en un archivo puede acelerar la aplicación 20 veces!), Pero no tengo idea si la creación de nuevas clases y objetos ralentiza PHP por sí solo.

¿Alguien tiene alguna información al respecto?

Como varias otras personas han señalado, hay una sobrecarga moderada para OO PHP, pero puede compensarlo enfocando su esfuerzo de optimización en las clases principales de las que se derivan sus otras clases. Es por esto que C ++ se está volviendo cada vez más popular en el mundo de la computación de alto rendimiento, tradicionalmente el reino de C y Fortran.

Personalmente, nunca he visto un servidor PHP que tuviera restricciones de CPU. Verifique el uso de la RAM (también puede optimizar las clases principales para esto) y asegúrese de no hacer llamadas innecesarias a la base de datos, que son órdenes de magnitud más caras que cualquier trabajo adicional de CPU que esté realizando.

El uso de grandes marcos para aplicaciones web que en realidad no requieren un número tan grande de clases para todo es probablemente el peor problema que muchos no conocen. Bájelo al menos para no incluir cada bit de código, mantenga solo lo que necesita y deseche el resto.

Esto me molesta. Ver ... el código de procedimiento no siempre es un código de espagueti, pero los fanáticos de OOP siempre suponen que sí lo es. He escrito varias aplicaciones web basadas en procedimientos, así como un demonio de servicios IRC en PHP. Sorprendentemente, parece superar a la mayoría de los otros que están ahí fuera y editarlo es muy fácil. Uno de mis amigos que generalmente hace OOP lo miró y dijo que "ningún código tiene derecho a ser así de limpio"

Un buen programador puede escribir un excelente código de procedimiento sin que traigan las clases generales. Un mal programador siempre escribirá código OOP de mala calidad que ralentiza las cosas.

No hay una respuesta correcta a la que sea mejor para PHP

Hay formas de limitar la penalización de las entradas de include_once, y eso es al tener funciones declaradas en el archivo ''include_once'' que a su vez tienen su contenido de código en una declaración de ''include''. Esto cargará su biblioteca de código, pero solo las funciones que se estén utilizando cargarán el código cuando sea necesario. Toma un segundo archivo de acceso al sistema para el código incluido, pero los usos de la memoria se reducen prácticamente a la biblioteca, y solo se carga el código utilizado por su programa. El impacto del segundo acceso al sistema de archivos se puede mitigar mediante el almacenamiento en caché. Cuando se trata de un gran proyecto de PHP basado en procedimientos, esto proporciona un bajo uso de memoria y un procesamiento rápido. NO hagas esto con las clases. Esto sería para una instancia de producción, un servidor de desarrollo mostrará toda la penalización de accesos ya que no desea que el almacenamiento en caché esté activado.

Lo más importante a recordar es, diseñar primero, optimizar después. Un mejor diseño, que sea más fácil de mantener, es mejor que el código de espagueti. De lo contrario, también podría escribir su aplicación web en ensamblador. Una vez que haya terminado, puede hacer un perfil (en lugar de adivinar) y optimizar lo que parece más lento.

Puede reconsiderar para repensar la estructura de sus clases y cómo implementarlas. Si dijiste que la POO es más lenta, es posible que tengas que rediseñar tus clases y cómo implementarlas. Una clase es solo una plantilla de un objeto, cualquier método mal diseñado afecta a todos los objetos de esa clase.

Use la herencia y el polimorfismo lo más que pueda, esto reducirá efectivamente la cantidad de comportamientos y métodos independientes que necesitan sus clases, pero primero necesita todo lo que necesita para crear un buen mapa de herencia, abstrayendo sus clases primarias o primitivas tanto como pueda.

No es un problema sobre cuántas clases tiene, el problema es cuántos métodos, propiedades o campos tienen y qué tan bien están estructurados esos métodos. La herencia reduce la cantidad de métodos para diseñar dramáticamente y la cantidad de código para compilar también.

Sí, cada inclusión hace que su programa sea más lento, pero hay más que eso.

Si descompones tu programa en muchos archivos, hay un punto en el que estás incluyendo / analizando / ejecutando la menor cantidad de código, en comparación con la sobrecarga de incluir todos esos archivos.

Además, tener muchos archivos con poco código no es tan malo, ya que, como dijiste, usar cosas como eAccelerator, o APC, es una forma trivial de recuperar un montón de rendimiento. Al mismo tiempo, si crees en ellos, obtienes todos los maravillosos beneficios de tener una base de código orientada a objetos.

Además, disminuya la cantidad por solicitud! = No escalable.

Actualizado

Según lo solicitado, PHP es aún más rápido en la manipulación de arreglos directos que en las clases. Recuerdo vagamente el proyecto ORM de la doctrina, y alguien que compara la hidratación de los arreglos con los objetos, y los arreglos salieron más rápido. Sin embargo, no es un orden de magnitud, es notable. Está en francés, pero el código y los resultados son completamente comprensibles. . Solo una nota, esa doctrina utiliza los métodos mágicos __get y __set mucho, y estos también son más lentos que un acceso variable explícito, parte de la lentitud de la hidratación de objetos de doctrine podría atribuirse a eso, por lo que lo consideraría como el peor de los casos. Por último, incluso si está utilizando matrices, si tiene que moverse mucho en la memoria, o en toneladas de pruebas, como isset, o funciones como ''in_array'' (orden N), atornillará el rendimiento. beneficios También recuerde que los objetos son solo matrices debajo, el intérprete los trata como algo especial. Yo, personalmente, preferiría un código mejor que un pequeño aumento de rendimiento, obtendrás más beneficios al tener algoritmos más inteligentes.

Si diseña un enorme objeto OOP, que hace todo en lugar de realizar una descomposición funcional en varias clases, obviamente llenará la memoria con un código de balasto inútil. Además, con un marco lento no harás un mundo simplemente hola tan rápido. Me di cuenta de que es una tendencia amable (mala costumbre) que para un solo ícono de Facebook, las personas incluyan una increíble biblioteca de fuentes y luego a continuación hay un ícono de búsqueda con Fontello incluido. Cada vez que logran algo inusual, conectan un marco completo. Si desea crear una aplicación oop de carga rápida, use un marco solo como zephir-phalcon o lo que sea que desee y apéguese a él.

Si está utilizando include_once (), está provocando una desaceleración innecesaria, independientemente del diseño de POO o no.

OOP agregará una sobrecarga a su código, pero apostaré a que nunca lo notará.

Si su proyecto contiene muchos archivos y debido a la naturaleza de las restricciones y comprobaciones de acceso a archivos de PHP, recomendaría activar realpath_cache , aumentar los ajustes de configuración a números razonables y desactivar open_basedir y safe_mode . Asegúrese de usar PHP-FPM o SuExec para ejecutar el proceso php bajo un ID de usuario que está restringido a la raíz del documento para recuperar la seguridad que generalmente se obtiene de open_basedir y / o safe_mode .

Aquí hay algunos consejos sobre por qué esto es una ganancia de rendimiento:

También considere mi comentario sobre la respuesta de @ Ólafur:

Descubrí que especialmente la carga automática es la mayor desaceleración. PHP es extremadamente lento para la búsqueda de directorios y el acceso a archivos abiertos, cuanta más función PHP use durante un cargador automático personalizado, mayor será la desaceleración. Puede ayudarlo un poco desactivando el modo seguro (de todos modos, en desuso) o incluso open-basedir (pero no lo haría), pero la mayor mejora proviene de no usar la carga automática y simplemente usar "require_once" con fs completo pathes para requerir todas las dependencias por archivo php que utilice.