Parser Smarty'ego rozłożyłem dosłownie na czynniki pierwsze i stwierdziłem, że najlepiej napiszę go w podobnym stylu, co oni. Z paru powodów będę musiał całkowicie przerobić tzw. konfigurowalne źródła danych, poważnie rozważam nawet powrót programowania proceduralnego w tym elemencie. Zebrane dane ujawniły kilka niepokojących rzeczy.
- W Smarty'm źródła danych w ogóle nie odpowiadają za skompilowane szablony, dzięki czemu można je było załączać zwykłym include. W OPT zostawiłem tę możliwość, ale chyba z niej także zrezygnuję na korzyść tego polecenia.
- W jednym z artykułów wyczytałem, że odwoływanie się do funkcji oraz zmiennych lokalnych jest szybsze, niż do pól i metod klasy. Zrobiłem odpowiednie testy, różnica jest doskonale widoczna. Test z użyciem funkcji wykonywał się w czasie ok. 0,00038 sekundy, a kod obiektowy, 0,00049 sekundy. Jaki stąd wniosek? OPT, jak każdy system szablonów, jest wąskim gardłem i często jego wydajność jest kluczowa. Konfigurowalne źródła danych piszemy raz na długi czas, a ponadto jest to tylko sprawa wewnętrzna biblioteki, dlatego w ich przypadku z obiektowego wariantu można zrezygnować. Jednocześnie mam kolejny argument, by nie dać się ponosić różnym modom itd. bez względu na mój b. pozytywny stosunek do OOP :).
- Kluczowe znaczenie dla wydajności systemu szablonów mają funkcje systemu plików. Pod test z forum php.pl podstawiłem spreparowaną wersję OPT RC-2, w której dokonałem małego uproszczenia. Mianowicie jeżeli już wcześniej parsowaliśmy dany szablon, biblioteka nie wykonywała ponownie testów czasu modyfikacji funkcjami filemtime(). Rezultat był piorunujący. Czas wykonywania zmniejszył się DZIESIĘCIOKROTNIE. Dokumentacja mówi, że wyniki ww. funkcji są cache'owane, w co nie bardzo wierzę, patrząc na efekty. Niemniej skoro tak jest, rozwiązanie takie mógłbym także wprowadzić ku rozpaczy twórców wszelkiego rodzaju benchmarków ;D.
- Kiedy zrobiłem wszystko tak, jak w Smarty'm, OPT nadal przegrywał niewielkimi kawałkami. Szablon liczył 10 kB i wstawionych było do niego 20 bloków. Dla zabawy na koniec pliku dokleiłem jeszcze 100 bloków i OPT bardzo, ale to bardzo zwolnił. Oba systemy szablonów generują nieco inny kod wynikowy. Smarty tworzy statyczny HTML ze wstawkami PHP, OPT jedną wielką wstawkę PHP z HTML'em jako ciągiem. Według zachodnich programistów, miało to OPT'kowi dawać znaczącą przewagę przy dużej liczbie instrukcji w szablonie (parser PHP nie musiałby się przełączać co chwila między trybem HTML, a PHP). Moje wcześniejsze testy też niby to wykazywały, a teraz okazało się to zupełną lipą. Jeśli podmienię OPT'kowi skompilowany szablon na ten ze Smarty'ego, wszystko wraca do normy i czasy obu bibliotek są już równe.
Tak więc widzicie, że bibliotekę czeka parę poważnych zmian. Zrzynanie od Smarty'ego wcale nie jest takie złe. Pamiętajmy, że nad tym parserem siedzieli sami twórcy PHP, więc z pewnością lepiej ode mnie wiedzą, jak prawidłowo wykorzystywać poszczególne elementy języka.
Napisał radziel w piątek, 17 lutego 2006 o 18:33
U mnie OPT odczuwalnie zwolnił gdy wrzuciłem 2 postfiltry które odpowiadały za przerabianie linków z "?a=xxx&b=yyy" na "/_/a_xxx/b_yyy". Gdy ten sam kod (filtra) wykonywałem po "przetworzeniu szablonu" ale przed wysłaniem go do użytkownika (ręcznie go przechwytując) czas o pare 0,01 się skrócił.
Wniosek? Czyżby OPT "dławił się" na obsłudze ładowanych z zewnątrz filtrów?