OPTv2 tak samo wydajny, jak OPTv1

listopad 24th, 2008 · 2 Comments ·

Kilka dni temu Zyx zakomunikował światu, iż Open Power Template został prawie ukończony. Wydana została ostatnia wersja developerska (2.0.0-dev8). Jeśli wierzyć zapewnieniom Zyxa, zostało mu już tylko napisać kilkaset testów PHPUnit. Wtedy będzie wiadomo, czy 2.0.0-dev8 stanie się finalną wersją, czy wyszły na jaw jakieś błędy ;)

Gdy Zyx pracuje, Nowaker zastanawia się nad wydajnością nowego OPT. Jak wiadomo, OPTv2 jest zgodny ze składnią XML. Chcąc nie chcąc, przetwarzanie XML-a jest zawsze wolniejsze… Ale nie w OPTv2 :) W tym przypadku Zyx dość solidnie zoptymalizował algorytmy przetwarzania szablonów XML-owych.

Wykonałem dwa krótkie testy wydajności na Apache Benchmark (ab -n 1000 -c 10). Pierwszy zawierał tylko jedną zmienną, drugi zawierał dziesięć prostych sekcji. Na jedno wywołanie skryptu PHP generowanych było 30 szablonów - w moich aplikacjach zdarza mi się parsować taką ilość szablonów w trakcie jednego wywołania skryptu. Wyniki:

	OPTv1	OPTv2
Test 1	65.27	68.79
Test 2	31.36	30.32

Jak widać, OPTv2 jest prawie tak samo wydajny, jak OPTv1. Różnica między nimi wynosi maksymalnie 5%. Co ciekawe, szablon z sekcjami wykonał się nieco szybciej na OPTv2. Gratuluję :)

Ten mini-benchmark wykonałem z czystej ciekawości. Nawet 3 rzędy gorszy wynik OPTv2 nie zniechęciłby mnie z korzystania z tej biblioteki. Jestem zdecydowanym zwolennikiem pisania kodu na wyższym poziomie abstrakcji, co pozwala skupić się na wydajnym pisaniu kodu, bez zastanawiania się nad sprawami drugorzędnymi.

Odwiedź również:

P.S. Proszę nie sugerować się taką małą ilością żądań na sekundę. Domowy serwer to wiekowy blaszak.

Tags: Programowanie · XML - Extensible Markup Language

2 responses so far ↓

Zyx // listopada 25, 2008 at 21:38

Ooo, jestem mile zaskoczony takimi wynikami, bo po uobiektowieniu i rozbiciu na wiele małych plików spodziewałem się czegoś innego :).

Komentarza wymagają wzmianki o XML-u. Podczas normalnej pracy przetworzenie szablonu sprowadza się do zrobienia require() na skompilowanym wcześniej szablonie :). Kompilacja uruchamiana jest jedynie w przypadku modyfikacji źródłowego pliku i wtedy też do akcji wkracza parser XML. Nowy kompilator faktycznie zużywa znacznie więcej zasobów, niż ten z “jedynki”, ale wynika to z faktu, że do przetworzenia jest po prostu więcej danych. W OPT 1.x znaczniki XHTML były statycznym tekstem i zajmowały w zasadzie tyle pamięci, ile bajtów okupowały w pliku źródłowym. Teraz dla każdego tworzony jest przynajmniej jeden obiekt drzewa XML wypełniony rozmaitymi informacjami. I tak jak w jedynce kompilator jechał po góra kilkunastu węzłach, teraz do przetrawienia może iść nawet parę tysięcy - jednak robi to dlatego, by umożliwiać rzeczy, których zwykły PHP nie będzie nigdy potrafił :). Rekurencji natomiast pozbywałem się bardziej, by uniknąć przepełnienia stosu i błędów “Nesting level too deep”, bo złożoność samych algorytmów pozostała w zasadzie bez zmian.

Sekcje faktycznie mogą działać szybciej, bo domyślnie kompilowane są teraz jako (szybsza) pętla “for”, a nie “foreach”. Jednak z drugiej strony pojawiło się coś takiego, jak “formaty danych” i zachowanie sekcji można teraz relatywnie prosto przeprogramowywać na dowolny sposób. W szczególności, do iteracji po obiektach wciąż można wybrać “foreach”.

A OPT 2.0.0-dev8 nie będzie na pewno wersją finalną, gdyż w kodzie zostało jeszcze kilkanaście komentarzy “TODO” oznaczających jakieś nieduże rzeczy do dodania (w stylu weryfikacji dodatkowego warunku, sprawdzenia pewnego zachowania czy zaimplementowania całej metody, jak to ma miejsce w przypadku Opt/Xml/Cdata.php :)).
Nowaker // listopada 25, 2008 at 21:48

Zwiększone użycie pamięci przez kompilator OPTv2 w stosunku do poprzednika zauważyłem - zajmował 2-3 razy więcej. Jednak, co ciekawe, czas ładowania się zarówno OPTv1 i OPTv2 był w przybliżeniu równy, ewentualnie na korzyść dla OPTv2 o 0.001 s. ;-)

#!/bin/nwkr devblog