Comparaciones de velocidad - Procedural vs. OO en idiomas interpretados

Question

En lenguajes de programación interpretados, como PHP y JavaScript, ¿qué repercusiones tiene 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 cosas a considerar 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 lo hay) es el rendimiento realmente alcanzado, al ir con OO vs Procedural en un lenguaje interpretado?

Answer 1

Tal vez estoy loco, pero la preocupación por la velocidad en casos como este usando un lenguaje interpretativo es como tratar de averiguar qué color pintar el cobertizo. Ni siquiera nos metamos en la idea de que este tipo de optimización es completamente prematura.

Golpeó el clavo en la cabeza cuando dijo '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.

Answer 2

Conclusión: no, porque la sobrecarga de la interpretación sobrepasa la sobrecarga del envío de métodos.

Answer 3

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.

Answer 4

De hecho, he hecho una pequeña prueba como esta en python en un sitio web que mantengo y encontré que son casi equivalentes en velocidad, con el enfoque de procedimiento ganando algo así como diezmilésimas de segundo, pero que el OO el código era tan significativamente más limpio que no continué el ejercicio más de una iteración.

Así que realmente, no importa (en mi experiencia de todos modos).

Answer 5

Su rendimiento se caracterizará por la implementación, no por el idioma. 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.

Recuerde la primera regla de optimización.

No.

:)

Answer 6

Lamentablemente, he hecho mis pruebas también. Probé la velocidad, y es casi lo mismo, pero cuando probaba el uso de la 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?

Answer 7

En mi experiencia, un sitio con mucha carga se atascará 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.

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 OOP. 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.