Ponieważ kod PHP będzie działał dobrze, nawet jeśli jest on pełen ostrzeżeń i zawiadomień o niezdefiniowanych indeksach i metodach nie statycznych nazywanych statycznymi, itp., Pytanie brzmi, czy poświęcam czas na usunięcie WSZYSTKICH powiadomień i ostrzeżeń z mojego kodu czy będzie znacznie szybsze? Czy php działa szybciej bez ostrzeżeń?
Zrobiłem zakładkę do artykułu, w którym autor dokonał pewnych testów porównawczych; niestety, to po francusku ... ale tutaj jest (być może będzie zrozumieć niektóre jego części): Ne faites pas d'erreur
A oto numery, aby pomóc ludziom, którzy nie czytają francuski:
error_reporting i display_errors włączona: 5,162.76 msdisplay_errors niepełnosprawne: 136.18 mserror_reporting wyłączona też: 117.79 msco oznacza, że tak, kod PHP działa szybciej bez powiadomienia/ostrzeżenia/błędów, nawet jeśli te nie są wyświetlane ani nie zgłosił.
Derick Rethans mówi to samo w tym artykule: Five reasons why the shut-op operator (@) should be avoided(cytowanie):
Powód 3: To jest powolny (część 2)
Ilekroć PHP generuje błąd wewnętrznie, jest przetwarzany i sformatowany do formatu w pełni sformatowanego komunikatu, który może być aight do przeglądarki.
Tylko tuż przed wyświetleniem jest sprawdzane ustawienie
. To jednak nie jest związane wyłącznie z @ -operator.
Komunikat o błędzie jest zawsze w pełni sformatowany: , zanim sprawdzonoerror_reporting- lubdisplay_errorsw tej sprawie.
Zależy od ilości ostrzeżeń, ale obsługa błędów w PHP jest, nawet przy ukrywaniu komunikatów o błędach, stosunkowo kosztowna.
Co trzeba było zrobić, aby oszacować efekt jest profilowania na poziomie C: Instalacja valgrind (zakładając, że jesteś na Linuksie), a następnie uruchomić
callgrind /path/to/bin/php /path/to/script.php
ten generuje plik o nazwie callgrind.12345 lub tak, załaduj ten plik do aplikacji, takiej jak kcachegrind i poszukaj php_error_docref0 lub php_error_cb, aby sprawdzić, ile czasu zostało poświęcone na obsługę błędu.
Proszę pamiętać o dokumentach cachegrind i valgrind, kiedy to robisz i pamiętaj, że w grę wchodzi wiele zmiennych zależnych od systemu.
EDYCJA: Oh jeszcze jedna uwaga: Zakładam, że sposób więcej czasu spędza się podczas rozmowy z bazami danych i podobnych systemów. i jeszcze jedna dodatkowa uwaga: poprawianie notatek zazwyczaj czyni kod bardziej odpornym na przyszłe zmiany, więc jest to dobry pomysł niezależny od wydajności.
+1 do edycji :-) – TheHippo
Nie nazwałbym tego "znaczącym" ulepszeniem w większości przypadków, ale uruchamianie kodu, który nie generuje żadnych błędów, przebiega naturalnie szybciej niż kod, który musi generować ślad stosu co drugą linię.
Sprawdź: http://www.noamdesign.com/Web-Design-Blog/15-tips-to-optimizing-your-php-code/, aby uzyskać więcej informacji na temat drobnych optymalizacji, które możesz wprowadzić w swoim kodzie.
Z własnego doświadczenia wynika, że 95% optymalizacji kodu zazwyczaj dotyczy sposobu korzystania z bazy danych.
Huh, zdałem sobie sprawę po wysłaniu: to jest moja tysięczna odpowiedź ^^ –
+1 do końcowego testu. Powiadomienia i ostrzeżenia to najgorsze błędy, ponieważ nie zmuszają cię do natychmiastowego rozwiązania problemu. Brakujące indeksy tablicowe są tak łatwe do naprawienia, ale zbyt rzadko są rozwiązywane. Osobiście traktuję każde powiadomienie/ostrzeżenie tak, jak to jest E_FATAL. – Dereleased
Teraz pytanie brzmi, czy sprawdzenie błędu nie spowoduje więcej opóźnień niż obsługa. Mam na myśli: testowanie na istnienie itd. Nie zrozum mnie źle: nienawidzę ostrzeżeń i zawiadomień. Niedawno dostałem taki projekt, ale wyniki powyżej nie przekonały mnie do zainwestowania. – Galvani