Tak też zrobiłem. Obok dotychczasowej metody parsującej: do_parse(), pojawiła się druga, do_include(), dedykowana specjalnie instrukcjom {include}. Różni się ona od pierwowzoru paroma rzeczami. Po pierwsze, nie ma tu kodu odpowiedzialnego za cache'owanie wyjścia HTTP oraz obsługi dyrektywy show_source. Pierwsza zmiana była właściwie niezbędna, by działało ono z tą instrukcją tak, jak należy i prędzej czy później i tak bym ją wprowadził. Na drugą zdecydowałem się ze względów estetycznych :). Jest też parę innych zmian. Otóż nazwa każdego skompilowanego w ten sposób szablonu zapisywana jest w specjalnej tablicy. Przed rozpoczęciem parsowania OPT sprawdza, czy w danym żądaniu dołączał dany plik poprzez {include}. Jeżeli tak - pomija testy istnienia pliku, czy konieczności rekompilacji szablonu. Dało to skryptowi potężnego kopa. Napisałem skrypt testowy, dołączający 80 razy krótki szablonik z treścią "blebleble". Pierwotny wynik przetwarzania to ok. 0,12 sekundy. Po zastosowaniu optymalizacji spadł do 0,06 s.
To jednak nie wszystko. Na wyraźne żądanie programisty OPT może posunąć się jeszcze dalej i dołączyć szablon już na etapie kompilacji, całkowicie eliminując wywołanie do_include(). Wszystko wygląda tak, jakbyśmy mieli tylko jeden szablon. Rozwiązanie to ma parę wad. Przede wszystkim skompilowane szablony mogą zajmować znacznie więcej miejsca na dysku. Drugi problem to niemożność rozpoznania przez OPT zmian w dołączanym szablonie. Jeśli jednak nie przeszkadza to nam, możemy śmiało włączyć pełną optymalizację. Na ww. skrypcie testowym otrzymałem przy jej pomocy najlepszy rezultat: 0,00473 s.
Ad. powyższego paragrafu - OPT optymalizuje tak tylko niektóre {include}'y. Mianowicie muszą one znajdować się w pętli oraz mieć statycznie przypisaną nazwę pliku (określoną już w momencie kompilacji szablonu).
