Pętla for

Dziś na warsztat trafiła pętla for. Istnieje kilka legend na jej temat. Standardowo implementuje się ją według sposobu pierwszego. Natomiast wiele źródeł wskazuje, by w warunku zakończenia pętli nie umieszczać wywołań jakiejś funkcji, ponieważ wywoływanie jej po każdym obiegu pętli może ją znacząco spowolnić. Zamiast tego powinniśmy obliczać warunek stopu na zewnątrz pętli jak pokazuje sposób drugi. Można również obliczać warunek stopu w instrukcji inicjalizującej i zamiast inkrementacji skorzystać z dekrementacji, czyli sposób trzeci. Jest to trochę mało intuicyjne i zawsze zastanawiam się czy pętla wykona się dokładnie tyle razy ile powinna. Ale dzięki temu nie tworzymy ani dodatkowej zmiennej, ani nie wywołujemy żadnej funkcji w warunku stopu.

Ale, ale, to nie wszystko. PHP może być zoptymalizowane pod kątem funkcji wbudowanych w PHP, a raczej funkcje wbudowane mogą być bardzo dobrze zoptymalizowane. Jak zmienią się wyniki testów, jeżeli funkcja w warunku stopu będzie faktycznie czasochłonna? Teoretycznie PHP mógłby wykazać się nieco inteligencją i zamieniać pętle ze sposobu pierwszego na sposób trzeci.

Żeby to sprawdzić, wykonujemy te same testy dla wszystkich powyższych sposobów z użyciem powolnej wersji funkcji count.

Kod

Funkcja testująca dostępna tutaj: benchmark.php

Wyniki

Okazuje się, że już dla wbudowanej funkcji count. różnice są zauważalne. Zwróćcie szczególną uwagę na to, że tablica ma tylko 1000 elementów. Zatem w tym przypadku warto wyrobić sobie nawyk tworzenia optymalnych pętli i tworzyć je najlepiej według sposobu trzeciego. Sposób pierwszy też nie jest zły w porównaniu do sposobu trzeciego, jednak dodatkowa zmienna nie jest zbyt elegancka, a w dodatku podnosi czas wykonywania pętli.