Dado que el código PHP funcionará bien incluso si está plagado de advertencias y avisos sobre índices indefinidos y métodos no estáticos que se llaman estáticos, etc., la pregunta es si pierdo el tiempo para eliminar TODOS los avisos y advertencias de mi código ¿funcionará significativamente más rápido?¿Funciona php más rápido sin advertencias?
He marcado un artículo en el que el autor hizo algunos puntos de referencia sobre eso; por desgracia, es en francés ... pero aquí es (tal vez vas a entender algunas partes de ella): Ne faites pas d'erreur
Y aquí están los números, para ayudar a las personas que no leen francés:
error_reporting y display_errors habilitadas: 5,162.76 msdisplay_errors discapacitados: 136.18 mserror_reporting desactivados demasiado: 117,79 msLo que significa que, sí, el código PHP se ejecuta más rápido y sin avisos/advertencias/errores, incluso cuando aquellos no se muestran ni informado.
Derick Rethans dice lo mismo en este artículo: Five reasons why the shut-op operator (@) should be avoided(citando):
Razón 3: Es lento (parte 2)
Siempre PHP genera un error mensaje internamente, se procesa y formateado todo el camino hasta el mensaje formateado que puede ser con salida str Aight para el navegador.
Solo antes de que se muestre, la configuraciónerror_reportingestá marcada. Sin embargo, esto no está relacionado con el operador @ @ exclusivamente.
El mensaje de error tiene siempre el formato completo antes de marcarerror_reportingodisplay_errorspara el caso.
depende de la cantidad de advertencias, pero la manipulación en PHP error es decir, incluso cuando ocultar mensajes de error, relativamente caro.
Lo que se tiene que hacer para estimar el efecto está perfilando en el nivel C: Instalar valgrind (asumiendo que usted está en Linux) y luego ejecutar
callgrind /path/to/bin/php /path/to/script.php
esto genera un archivo llamado callgrind.12345 más o menos, cargue este archivo en una aplicación como kcachegrind y busque php_error_docref0 o php_error_cb para ver cuánto tiempo se pasó en el controlador de errores.
Tenga en cuenta los documentos cachegrind y valgrind cuando haga eso y tenga en cuenta que hay muchas variables dependientes del sistema implicadas.
EDIT: Oh, una nota más: Supongo que manera pasa más tiempo al hablar con bases de datos y sistemas similares. y otra nota adicional: la fijación de avisos generalmente hace que el código sea más robusto para cambios futuros, por lo que es una buena idea, independientemente del rendimiento.
1 para la edición :-) – TheHippo
No lo llamaría una mejora "significativa" en la mayoría de los casos, pero ejecutar código que no genera errores de ningún tipo, naturalmente, se ejecuta más rápido que el código que genera un seguimiento de la pila cada dos líneas.
Consulte: http://www.noamdesign.com/Web-Design-Blog/15-tips-to-optimizing-your-php-code/ para obtener más información sobre optimizaciones menores que puede realizar en su código.
En mi propia experiencia, he descubierto que el 95% de la optimización de código generalmente trata sobre cómo usa su base de datos.
Eh, me di cuenta después de publicar: este es mi número 1.000 respuesta ^^ –
1 para la prueba final. Los avisos y las advertencias son sus peores errores específicamente porque no lo obligan a solucionar el problema de inmediato. Los índices de matriz faltantes son tan fáciles de corregir, pero rara vez se abordan. Personalmente, trato cada aviso/advertencia como si fuera E_FATAL. – Dereleased
Ahora, una pregunta es si la comprobación de errores no causará más demora que el controlador. Quiero decir: probar la existencia, etc. No me malinterpreten: odio las advertencias y avisos. Hace poco recibí un proyecto de este tipo, pero los resultados anteriores no me convencen para invertir el dinero. – Galvani