PSR-1 i PSR-2

UWAGA! Ten wpis ma już 7 lat. Pewne stwierdzenia i poglądy w nim zawarte mogą być nieaktualne.

Tym razem krótko, bo chciałem tylko zaznaczyć istnienie PSR-1 i PSR-2. Cieszę się, że te dwa zalecenia powstały i że modne jest stosowanie się do nich, przez co istnieje duże prawdopodobieństwo, że przeglądając źródła zarówno swojego projektu, jak i innych, dostępnych publicznie, a często używanych, trafimy na czytelne i zbieżne formatowanie. Sam musiałem wyplenić kilka złych nawyków, ale dzięki kod jest dużo czytelniejszy.

Wojny edycyjne uznajemy więc za zakończone. 😉

Korzystanie z stdout jest wolne

UWAGA! Ten wpis ma już 8 lat. Pewne stwierdzenia i poglądy w nim zawarte mogą być nieaktualne.

Całe życie byłem przekonany, że wypluwanie danych do stdout jest najszybszym sposobem prezentowania postępu działania aplikacji działającej w CLI. I dopiero parę dni temu, przez przypadek, dowiedziałem się, że grubo się myliłem.

Weźmy na warsztat prosty skrypt:

$start = microtime(true);

for($i = 0; $i < 1000000; $i++) {
    echo 'New line' . PHP_EOL;
}

$stop = microtime(true);

$totalTime = $stop - $start;

echo 'Execution time: ' . $totalTime . PHP_EOL;

Wykonanie w moim przypadku zajmuje ~6,5 s.

Podobny skrypt uruchomiłem niedawno przez przypadek w pracy, jednak zapomniałem odkomentować wyświetlania linii tekstu. Skrypt wykonał się… praktycznie od razu.

Zakomentujmy więc linię zawierającą echo 'New line’ . PHP_EOL; . Po tym zabiegu wykonanie skryptu trwa ok. 0,16 s. Różnica jest więc ogromna.

Po chwilowym szukaniu informacji na ten temat, pomocny okazuje się jak zwykle wątek na stackoverflow. W skrócie: stdout nie jest przystosowany do przetwarzania dużej ilości informacji, natomiast „fenomen” zauważony przez pytającego (zapis na dysk jest szybszy od wyplucia danych do stdout) wynika z buforowania. Dodatkowo, są duże różnice pomiędzy poszczególnymi emulatorami terminala.

Na przyszłość będę więc oszczędniejszy w korzystaniu z stdout, zwłaszcza, gdy zależy na czasie.