performance - Comparaciones de velocidad-Procedural vs. OO en idiomas interpretados
oop maintainability (7)
En pocas palabras: no, porque la sobrecarga de la interpretación abruma la sobrecarga del envío de métodos.
En lenguajes de programación interpretados, como PHP y JavaScript, ¿cuáles son las repercusiones de ir con un enfoque orientado a objetos sobre un enfoque de procedimiento?
Específicamente, lo que estoy buscando es una lista de verificación de aspectos a tener en cuenta al crear una aplicación web y elegir entre enfoques procedimentales y orientados a objetos, para optimizar no solo la velocidad sino también la capacidad de mantenimiento. Los casos citados de investigación y prueba también serían útiles si conoce algún artículo que lo explore más a fondo.
En pocas palabras: ¿qué tan grande (si es que hay alguno) es el rendimiento alcanzado realmente, al ir con OO vs Procedural en un lenguaje interpretado?
Si está utilizando un lenguaje interpretado, la diferencia es irrelevante. No debe utilizar un lenguaje interpretado si el rendimiento es un problema. Ambos realizarán más o menos lo mismo.
Tal vez estoy loco, pero preocuparme por la velocidad en casos como este usando un lenguaje interpretativo es como tratar de descubrir qué color pintar en el cobertizo. Ni siquiera nos metamos en la idea de que este tipo de optimización es completamente prematura.
Golpeaste el clavo en la cabeza cuando dijiste "mantenibilidad". Elegiría el enfoque que es el más productivo y más sostenible. Si necesita velocidad más adelante, no va a proceder de cambiar entre paradigmas de codificación orientados a objetos o procedimientos dentro de un lenguaje interpretado.
De hecho, he hecho una pequeña prueba como esta en Python en un sitio web que mantengo y descubrí que son casi equivalentes en velocidad, con el enfoque de procedimiento ganando algo así como diezmilésimas de segundo, pero que el código OO era tan significativo limpiador No continué el ejercicio más de una iteración.
Entonces realmente, no importa (en mi experiencia de todos modos).
Su desempeño se caracterizará por la implementación, no por el lenguaje. Podría usar el lenguaje más lento y podría escalar para ser el sitio más grande del mundo siempre que lo diseñe a escala.
Solo recuerde la primera regla de optimización.
No lo hagas
:)
Desafortunadamente, también hice mis pruebas. Probé la velocidad, y es casi lo mismo, pero cuando probaba el uso de memoria obteniendo memory_get_usage () en PHP, vi un número abrumadoramente mayor en el lado OOP.
116,576 bytes para OOP a 18,856 bytes para procedimiento. Sé que "el hardware es barato", ¡pero vamos! 1,000% de aumento en el uso? Lo siento, eso no es óptimo. Y teniendo tantos usuarios visitando su sitio web de inmediato, estoy seguro de que su memoria RAM se quemaría o se agotaría. ¿Me equivoco?
En mi experiencia, un sitio bajo mucha carga se empantanará y dejará de responder mucho más fácilmente con el código OOP que con el procedimiento. La razón es fácil de entender.
OOP requiere muchas más asignaciones de memoria (MALLOC) y muchas más operaciones para ejecutar en la memoria que el código de procedimiento. Requiere mucho más tiempo de CPU para realizar sus tareas. Es esencialmente ''sobrecarga'', envuelto alrededor del código de procedimiento, lo que aumenta la carga de la CPU para ejecutarlo, especialmente al realizar operaciones de base de datos.
A muchos programadores les gusta la conveniencia de OOP, creando pequeñas cajas negras escondidas detrás de interfaces simples. Sin embargo, me han pagado bien para revivir sitios que tardaban una eternidad en responder bajo una gran carga de usuarios. Excluir el OOP y reemplazarlo con simples funciones de procedimiento hizo una gran diferencia.
Si no espera que su sitio esté muy ocupado, use POO. Si está construyendo un sistema de alto tráfico, querrá quitar cada ciclo de CPU del procesamiento y cada byte de la salida que pueda.