Poiché il codice PHP funzionerà correttamente anche se è pieno di avvisi e notifiche su indici non definiti e metodi non statici chiamati come statici, la domanda è, se passo il tempo a rimuovere TUTTE le notifiche e gli avvisi dal mio codice funzionerà più rapidamente? ?Il php funziona più velocemente senza avvertimenti?
Ho inserito un segnalibro in un articolo in cui l'autore ha effettuato alcuni benchmark; purtroppo, è in francese ... ma qui è (forse capirete alcune parti di esso): Ne faites pas d'erreur
E qui sono i numeri, per aiutare le persone che non leggono francese:
error_reporting e display_errors abilitati: 5,162.76 msdisplay_errors disabili: 136.18 mserror_reporting disabilitate anche: 117.79 msIl che significa che, sì, il codice PHP corre più veloce, senza comunicazioni/avvisi/errori, anche quando quelli che non vengono visualizzati né riportato.
Derick Rethans dice la stessa cosa in questo articolo: Five reasons why the shut-op operator (@) should be avoided(citando):
Motivo 3: E 'lento (parte 2)
Ogni volta che PHP genera un errore messaggio interno, è elaborato e formattato fino al messaggio formattato completamente che può essere in uscita tre al browser.
Solo poco prima che venga visualizzata l'impostazioneerror_reportingè selezionata. Tuttavia, questo non è correlato esclusivamente al @ -operator.
Il messaggio di errore è sempre completamente formattato prima cheerror_reportingsia selezionato odisplay_errorsper quella materia.
A seconda della quantità di avvisi, ma la gestione degli errori in PHP è, anche quando si nascondono i messaggi di errore, relativamente relativamente costoso.
Quello che avrebbe dovuto fare per stimare l'effetto è profiling a livello C: Installare valgrind (supponendo che si sta su Linux) e quindi eseguire
callgrind /path/to/bin/php /path/to/script.php
questo genera un file chiamato callgrind.12345 o giù di lì, carica questo file in un'app come kcachegrind e cerca php_error_docref0 o php_error_cb per vedere quanto tempo è stato speso nel gestore degli errori.
Si prega di prestare attenzione ai documenti cachegrind e valgrind quando si esegue questa operazione e si tenga presente che sono coinvolte molte variabili dipendenti dal sistema.
MODIFICA: Oh un'altra nota: presumo che il modo sia trascorso mentre si parla di database e sistemi simili. e ancora un'altra nota aggiuntiva: la correzione delle notifiche di solito rende il codice più solido per le modifiche future, quindi è una buona idea indipendente dalle prestazioni.
+1 per la modifica :-) – TheHippo
Non lo definirei un miglioramento "significativo" per la maggior parte dei casi, ma il codice in esecuzione che non genera errori di qualsiasi tipo è naturalmente più veloce del codice che deve generare una traccia di stack su ogni altra linea.
Check out: http://www.noamdesign.com/Web-Design-Blog/15-tips-to-optimizing-your-php-code/ per ulteriori informazioni sulle ottimizzazioni minori che è possibile apportare al codice.
Nella mia esperienza personale, ho riscontrato che il 95% dell'ottimizzazione del codice di solito si occupa dell'utilizzo del database.
Huh, mi sono reso conto dopo la pubblicazione: questa è la mia millesima risposta ^^ –
+1 per il test finale. Avvisi e Avvisi sono i tuoi peggiori errori in particolare perché non ti costringono a risolvere il problema immediatamente. Gli indici di array mancanti sono così facili da risolvere, ma troppo raramente indirizzati. Personalmente, tratto ogni avviso/avvertimento come se fosse E_FATAL. – Dereleased
Ora, una domanda è se il controllo degli errori non causerà più ritardo rispetto al gestore. Voglio dire: test per l'esistenza, ecc. Non fraintendetemi: odio avvertimenti e avvisi. Recentemente ho avuto un progetto simile, ma i risultati sopra riportati non mi convincono a investire la spesa. – Galvani