Kluczowe znaczenie w przypadku systemów szablonów mają tak naprawdę operacje dyskowe i to im powinniśmy się przyglądać w pierwszej kolejności. Każde załączenie nowego pliku, każdy "include" wymaga uruchomienia całej machiny przeszukiwania katalogów, ładowania danych do pamięci, blokowania dostępu, parsowania itd. - właśnie ten proces jest przede wszystkim rejestrowany w dobrze napisanych systemach, ponieważ przeważnie ilość kodu PHP biblioteki wykonywanego podczas wywołania display('template.tpl') jest znikoma.

Mierząc czas wykonywania, musimy pamiętać o sposobie działania narzędzia testującego. Opiszę to na przykładzie. Na własnym komputerze do porównywania wydajności OPT i Smarty'ego używam albo skryptu napisanego onegdaj przez Bastiona, na którym udowadniał swego czasu wyższość (pod względem wydajnościowym) swego Chameleona. Działał on na takiej zasadzie, iż ładował zainteresowane biblioteki, a następnie ileśtam razy pod rząd wywoływał w kółko tę samą funkcję, mierząc czas każdej iteracji z osobna. Można zatrzymać się w tym miejscu, mówiąc: "po #$%#$% mi więcej! Proszę, tu mam wyniki i wymiatam". Twierdzenie, iż taki test odzwierciedla wydajność systemu w świecie rzeczywistym to mit, gdyż wystarczy odrobinę pomyśleć, by dostrzec, iż odbywa się on w zupełnie innych warunkach! Symulowana jest tu sytuacja, kiedy w jednym żądaniu próbujemy wyświetlić 500 szablonów - oczywiście kod źródłowy biblioteki ładowany jest tylko jeden raz, a czas tego procesu nie jest nawet brany pod uwagę. Bardziej wiarygodne warunki oznaczają konieczność wysłania 500 osobnych żądań tak, aby każde z nich samodzielnie spróbowało wczytać kod źródłowy i odpalić 1-2 szablony, ponieważ właśnie tak odbywa się to naprawdę. Odpowiedni program do przeprowadzenia takiego benchmarku istnieje i nawet jest włączony do każdego wydania serwera Apache. Nazywa się ab, a znajdziemy go w katalogu "bin". Dopiero za jego pomocą dowiadujemy się, jak skrypt zachowa się w warunkach prawdziwego obciążenia.

Różnica między tymi dwoma podejściami jest widoczna gołym okiem. W pierwszej wersji OPT spokojnie bił Smarty'ego na głowę z ogromnym zapasem czasu. ab.exe pokazuje jednak, iż uwzględniając czas ładowania każdej z bibliotek, różnica ta znacząco się zaciera, a ubogi w opcje Chameleon był niewiele lepszy. Dodam tutaj, iż dwa lata temu, jeszcze przed rozpoczęciem prac nad OPT, za pomocą ab.exe mierzyłem sobie w sterylnych warunkach możliwości różnych systemów szablonów - o dziwo, Smarty rozłożył konkurencję w stylu fastTemplate czy phpLib na łopatki, ponieważ jako jedyny nie bawił się samodzielnie w maszynę wirtualną, tylko zwyczajnie prekompilował wszystkie szablony do poziomu tradycyjnego kodu PHP :).

Wobec tego niektórzy mogą posądzić mnie o kłamstwo, ponieważ twierdziłem, że OPT od Smarty'ego jest szybszy. I nadal tak twierdzę. Po pierwsze, warunki testu muszą być porównywalne: Smarty nie korzysta z wyjątków, więc z procedur testowych OPT musi zniknąć blok try{ ... }catch(). Smarty nie ma kompresji gZip, w OPT też jej nie włączamy; Smarty nie wysyła nagłówków, my również. Decydując się na opcję compile_check = false w Smarty'm, ustawiamy również analogiczną performance = true w OPT. Czy jest to oszustwo? Nie! Właśnie oszukiwanie było poprzednio - korzystając ze Smarty'ego, programiści i tak samodzielnie by musieli przynajmniej część z nich dodać, więc filozoficzne pytanie brzmi, dlaczego OPT ma mieć doliczony czas, ponieważ oferuje opcjonalną możliwość samodzielnego zajęcia się tym wszystkim automatycznie? Na takiej samej zasadzie ja mógłbym rzec, że skoro Smarty posiada znacznie szybszy kompilator, to może wystartować w teście z włączoną dyrektywą force_compile. Sensu w tym żadnego, dlatego przygotowując własne procedury, musimy dokładnie zastanowić się, jak je napisać, aby nie zafałszować wyników poprzez włączenie (lub nie) jakiejś opcjonalnej opcji jednemu z testowanych skryptów. Warunki muszą być jak najbardziej identyczne.

Bój OPT-Smarty każdy może we własnym zaciszu rozstrzygnąć na korzyść tego pierwszego, szczególnie jeśli wciąż siedzi w nim zakorzeniona ta przerośnięta kobyła :). W OPT znajduje się takie narzędzie, jak "OPT Configurator" pełniący rolę preprocesora. Jego zadanie polega na automatycznym usunięciu z biblioteki tych możliwości, z których nie korzystamy. Wyłączając w domu wszystko, co się dało, zmniejszyłem wielkość pliku opt.class.php do zaledwie 14 kB, przez co OPT dogonił Chameleona 1.5.0. Dodatkowo przestudiowałem kod źródłowy wygenerowanego pliku i dostrzegłem, iż wykonuje on niepotrzebnie każdorazowe załączanie dwóch plików; zakomentowanie tych linijek sprawia, że Chameleon zostaje w tyle.

Wpis ten powstał pod wpływem przetestowania rozwojowej gałęzi OPT programem ab.exe wykonanym właśnie po to, aby odnaleźć i wyłapać takie niuanse, dzięki czemu nadchodząca wersja 1.1.0 będzie jeszcze szybsza. Pragnąłem wykorzystać to jednocześnie do rozwiania paru mitów dotyczących wydajności systemów szablonów, opierając się na praktycznym doświadczeniu.

Tak przy okazji może mnie ktoś oświecić, co się z Chameleonem stało? Chciałem przetestować tę bibliotekę na jej najnowszej wersji, a tu spotkała mnie niespodzianka. Strona autora zawiera tylko nazwę domeny, serwer, na którym były pliki itd. informuje, iż domena jest na sprzedaż... dziwi mnie to tajemnicze zniknięcie, ponieważ tym projektem też się sporo osób interesowało.

Powrót

Na Zyxist.com panuje swoboda wyrażania opinii oraz krytyki pod dowolnym adresem. Jedyny warunek: musi być ona kulturalna i rzeczowa. Na chamstwo, prostactwo lub jawne obrażanie kogokolwiek nie ma tu miejsca i takie komentarze są bardzo szybko usuwane. Jeśli zamierzasz polemizować z treścią wpisu, wpierw uważnie ją przeczytaj.