Polska odpowiedź na SMARTY., Wysokowydajna klasa Gepard do zarządzania szablonami. Opcje

[harpcio]

Witam serdecznie wszystkich,

Jakiś czas temu napisałem klasę obiektową gepard, która służy do tworzenia szablonów dla aplikacji php.
Dzieki niej, jest możliwe całkowie odseparowanie kodu źródłowego php od kodu HTML.

Jej cechy charakterystyczne to prostota, szybkość działania oraz minimalna ingerencja w kod html.

Jeśli ktoś ma ochotę, proszę zajrzeć na stronę:
www.gepard.w.pl

Bardzo mile widziane wszelkie uwagi, opienie, wrażenia.

Pozdrawiam serdecznie!

Ten post edytował harpcio 5.01.2007, 11:37:58

[Zyx]

Rozbudowany system szablonów wcale nie musi być wolniejszy od minimalistycznego. Widziałem już wiele "małych" systemów, które nie wytrzymywały konkurencji ze "przeładowanym" Smarty'm (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) . Zrobiłem także Gepardowi mały teścik porównawczy: prosta stronka wyświetlająca liczby od 0 do 99, testowana programem Apache Bench (n == 500). Wyniki średnie:

- Gepard: 100.21 rps
- OPT: 99.06 rps

Różnice wydajnościowe są minimalne, a OPT jest niewiele szybszy od Smarty, który w tym samym teście osiągnąłby wobec tego podobną szybkość. Zwróćmy uwagę na pewną rzecz: jeśli na stronie mamy sześć różnych list, musimy utworzyć przynajmniej siedem klas Gepard i siedmiokrotnie załadować jakieś pliki z szablonami. Okazuje się, że bardzo odbija się to na wydajności. Przerobiłem nieco test, aby ukazał tę sytuację. Każdy z systemów miał wyświetlić liczby od 0 do 99 sześciokrotnie. Ponieważ nie chciało mi się wymyślać cudów, wszystkie w zasadzie miały identyczny kod, tylko Gepardowi sześć razy z osobna tworzyłem obiekt klasy, aby zasymulować sytuację, że wszystkie listy są inne. Rezultat:

- Gepard: 24.89 rps
- OPT: 87.47 rps

Prawdopodobnie da się umieścić wszystkie wersje listy w jednym pliku i obsługiwać je jedną klasą, lecz dokumentacja Geparda jest nienajlepsza - nawet przykłady tam zawarte preferują wielokrotne ładowanie tego samego pliku do pamięci, stąd też użyłem właśnie takiego podejścia.

Poniżej prezentuję kod php użyty do testów - przy okazji zwróć uwagę na długość obu z nich (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) .

1. Gepard:

[PHP] pobierz, plaintext 
<?php
 
require('./gepard/gepard_final.inc.php');
 
$strona = new Gepard('strona');
$strona -> CreateCode();
 
$lista = new Gepard('lista', 'lista');
 
for($i = 0; $i < 100; $i++)
{
	$lista -> AssignVar('item', $i);
	$lista -> CreateCode('repeat');
}
 
$lista = new Gepard('lista', 'lista');
 
for($i = 0; $i < 100; $i++)
{
	$lista -> AssignVar('item', $i);
	$lista -> CreateCode('repeat');
}
 
$lista = new Gepard('lista', 'lista');
 
for($i = 0; $i < 100; $i++)
{
	$lista -> AssignVar('item', $i);
	$lista -> CreateCode('repeat');
}
 
$lista = new Gepard('lista', 'lista');
 
for($i = 0; $i < 100; $i++)
{
	$lista -> AssignVar('item', $i);
	$lista -> CreateCode('repeat');
}
 
$lista = new Gepard('lista', 'lista');
 
for($i = 0; $i < 100; $i++)
{
	$lista -> AssignVar('item', $i);
	$lista -> CreateCode('repeat');
}
 
$lista = new Gepard('lista', 'lista');
 
for($i = 0; $i < 100; $i++)
{
	$lista -> AssignVar('item', $i);
	$lista -> CreateCode('repeat');
}
 
$strona -> CreateCode();
 
?>
[PHP] pobierz, plaintext 

2. OPT:

[PHP] pobierz, plaintext 
<?php
 
define('OPT_DIR', './opt/');
require(OPT_DIR.'opt.class.php');
 
	try
	{
		$tpl = new optClass;
		$tpl -> root = './templates/';
		$tpl -> compile = './templates_c/';
 
		$result = array();
		for($i = 0; $i < 100; $i++)
		{
			$result[] = array('item' => $i);
		}
		$tpl -> assign('lista', $result);
		$tpl -> parse('strona.tpl');
	}
	catch(optException $e)
	{
		optErrorHandler($e);
	}
?>
[PHP] pobierz, plaintext 

W OPT (oraz w Smarty'm) raz załadowanego zestawu danych mogę używać wielokrotnie w różnych miejscach, jeśli jest mi to potrzebne. W Gepardzie nie dość, że każde kolejne użycie musi być dodatkowo oprogramowywane w php, to jeszcze jest to porozrzucane dość nieładnie po kilku plikach. Przy większym projekcie zapewne bym się w tym pogubił.

Jeżeli dodawałbym do niej wszystko co się rusza i na drzewo nie ucieka , to tak, stanie się ociążałą, pozbawioną sensu maszkarą.

Argument "im więcej opcji, tym jest to wolniejsze" jest mitem. Tak naprawdę wszystko zależy od wykorzystanego sposobu kompilacji szablonów. Gepard całą mechaniką zajmuje się samodzielnie, co w przypadku prostych rozwiązań może dawać spore zyski, ale dla bardziej zaawansowanych faktycznie skutkuje coraz poważniejszym spadkiem wydajności (iterpreter interpretuje interpreter interpretujący kod). Smarty oraz OPT są w zasadzie kompilatorami, które cały szablon przetwarzają do postaci czystego kodu php, który w kolejnych odsłonach jest zwyczajnie dołączany np. przez include(). Dlatego instrukcje warunkowe, pętle itd. działają tam z taką samą prędkością, jak w php, ponieważ tak naprawdę one są napisane bezpośrednio w php, a nie interpretowane przez napisany w php interpreter. Trochę zawile to opisałem, ale myślę, że sens da się zrozumieć (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) . Oba systemy ładują podczas normalnej pracy jedynie fragment swego własnego kodu do pamięci. Kompilator oraz algorytmy przetwarzające znaczniki w szablonach na kod php wczytywane są tylko, gdy zachodzi potrzeba skompilowania czegoś. Dlatego w obu możesz mieć na dobrą sprawę nawet i tysiąc różnych instrukcji, ale podczas normalnego użytkowania nie odczujesz żadnego spadku wydajności z tego powodu, ponieważ kod ten będzie co najwyżej miejsce na dysku zajmował i nic ponadto.

--edit (sab) Poprawiłem bbcode listingów.