<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Komentarze do: OPTv2 tak samo wydajny, jak OPTv1</title>
	<atom:link href="http://www.nowaker.net/devblog/programowanie/xml-extensible-markup-language/optv2-tak-samo-wydajny-jak-optv1/feed" rel="self" type="application/rss+xml" />
	<link>http://www.nowaker.net/devblog/programowanie/xml-extensible-markup-language/optv2-tak-samo-wydajny-jak-optv1</link>
	<description>...czyli Nowakerowy blog o zmaganiach web developera, ale nie tylko.</description>
	<lastBuildDate>Mon, 23 Aug 2010 18:08:28 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Autor: Nowaker</title>
		<link>http://www.nowaker.net/devblog/programowanie/xml-extensible-markup-language/optv2-tak-samo-wydajny-jak-optv1/comment-page-1#comment-354</link>
		<dc:creator>Nowaker</dc:creator>
		<pubDate>Tue, 25 Nov 2008 19:48:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.nowaker.net/devblog/xml-extensible-markup-language/optv2-tak-samo-wydajny-jak-optv1#comment-354</guid>
		<description>&lt;p&gt;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. ;-)&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Zwiększone użycie pamięci przez kompilator OPTv2 w stosunku do poprzednika zauważyłem &#8211; 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. ;-)</p>]]></content:encoded>
	</item>
	<item>
		<title>Autor: Zyx</title>
		<link>http://www.nowaker.net/devblog/programowanie/xml-extensible-markup-language/optv2-tak-samo-wydajny-jak-optv1/comment-page-1#comment-353</link>
		<dc:creator>Zyx</dc:creator>
		<pubDate>Tue, 25 Nov 2008 19:38:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.nowaker.net/devblog/xml-extensible-markup-language/optv2-tak-samo-wydajny-jak-optv1#comment-353</guid>
		<description>&lt;p&gt;Ooo, jestem mile zaskoczony takimi wynikami, bo po uobiektowieniu i rozbiciu na wiele małych plików spodziewałem się czegoś innego :).&lt;/p&gt;

&lt;p&gt;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 &quot;jedynki&quot;, 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 &quot;Nesting level too deep&quot;, bo złożoność samych algorytmów pozostała w zasadzie bez zmian.&lt;/p&gt;

&lt;p&gt;Sekcje faktycznie mogą działać szybciej, bo domyślnie kompilowane są teraz jako (szybsza) pętla &quot;for&quot;, a nie &quot;foreach&quot;. Jednak z drugiej strony pojawiło się coś takiego, jak &quot;formaty danych&quot; 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ć &quot;foreach&quot;.&lt;/p&gt;

&lt;p&gt;A OPT 2.0.0-dev8 nie będzie na pewno wersją finalną, gdyż w kodzie zostało jeszcze kilkanaście komentarzy &quot;TODO&quot; 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 :)).&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Ooo, jestem mile zaskoczony takimi wynikami, bo po uobiektowieniu i rozbiciu na wiele małych plików spodziewałem się czegoś innego :).</p>

<p>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 &#8220;jedynki&#8221;, 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 &#8211; 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 &#8220;Nesting level too deep&#8221;, bo złożoność samych algorytmów pozostała w zasadzie bez zmian.</p>

<p>Sekcje faktycznie mogą działać szybciej, bo domyślnie kompilowane są teraz jako (szybsza) pętla &#8220;for&#8221;, a nie &#8220;foreach&#8221;. Jednak z drugiej strony pojawiło się coś takiego, jak &#8220;formaty danych&#8221; 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ć &#8220;foreach&#8221;.</p>

<p>A OPT 2.0.0-dev8 nie będzie na pewno wersją finalną, gdyż w kodzie zostało jeszcze kilkanaście komentarzy &#8220;TODO&#8221; 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 :)).</p>]]></content:encoded>
	</item>
</channel>
</rss>
