Хочу задать несколько ламерских вопросов об XML, DOM и прочем. Сейчас я разбираюсь с CMS, основанной на XSLT-преобразовании. Всё сделано следующим образом. Генерируется большой XML и XSL, они представлены в виде строк (!). Ни о каком изначальном генерировании DOM-дерева речи не ведётся. Именно 2 стринга, а затем

$domxml = domxml_open_mem(WinToUTF8($sectionXML));
$domxsl = domxml_xslt_stylesheet($sectionXSL);
$result = $domxsl->process($domxml);
echo $domxsl->result_dump_mem($result);

У меня такой вопрос. Насколько с точки зрения производительности, то есть скорости выполнения преобразования, это оптимально или не оптимально? (Именно производительность, удобство работы с DOM-деревом мы в расчёт не берём.) Сейчас всё происходит таким образом. Генерится большая строка, затем она распарсивается, распарсивается XSLT, и в конце производится преобразование.

Правильно ли я понимаю, что если изначально мы представляем структуру в виде DOM-дерева, то затем можно проводить преобразование без дополнительных потерь на парсинг XML?


Это сообщение отредактировал(а) dm9 - 19.9.2005, 16:00

Потери на парсинг не очень большие, по сравнению с самим преобразованием.

Цитата(dm9 @ 19.9.2005, 14:29)

Правильно ли я понимаю, что если изначально мы представляем структуру в виде DOM-дерева, то затем можно проводить преобразование без дополнительных потерь на парсинг XML?

Да можно, так будет лучше не только в плане производительности, но и просто удобней с документом работать. Скорее всего твоя CMS использует DOM, а потом в конце генерит текст XML.

XSLT это не преобразование XML в HTML, это преобразование любого дерева(XML) в любое дерево(XML, XHTML...). Прежде чем сгенерить HTML, можно проводить несколько трансформаций, собирая большой документ из различных источников.

Технически можно генерить всю (X)HTML страницу последним преобразованием, хотя мне проще генерить отдельные части контента через XSLT, а потом полученную вёрстку вставлять в простейший шаблон. Плюсы в возможности простого кеширования результатов преобразований.

Цитата(Sardar @ 19.9.2005, 17:27)

Скорее всего твоя CMS использует DOM, а потом в конце генерит текст XML.

Дык если бы.

Абсолютно всё делается таким образом:

Код

function GetXML() {       $xml = "<book                 id='{$this->id}'                 title='{$this->title}'                 author='{$this->author}'                 image='{$this->image}'";       if (InString($this->image, '|')) {          $str = explode('|', $this->image);          $xml.= " image_small='{$str[0]}' image_big='{$str[1]}'";       }       $xml.='>';       if ($this->type != null) {          $xml .= $this->type->GetXML();       }       $xml .= "{$this->text}</book>";       return $xml;     }

Вот, собственно, что меня и удивило...

Цитата(Sardar @ 19.9.2005, 17:27)

Потери на парсинг не очень большие, по сравнению с самим преобразованием.

Ты уверен в этом? Эти слова основаны на каких-то реальных тестах? Типичный размер XML будет от 30 до 80 килобайт...

Я понимаю, что это зависит от сложности XSLT-преобразования, конечно... Но хотелось бы примерные данные, сколько ms займёт парсинг 30-100 килобайтного XML...

Чувствую, придётся мне самому исследлваниями заниматься...

Ну дык сделай time() перед выполнением и вычти это из time() после выполнения и представляешь ввиде мс.

Уже...

Просто хотелось бы в сравнении с DOM получить результаты.

Вот, если кому интересно:

domxml_open_mem(WinToUTF8($sectionXML))
0,0633149147034 (много, блин...)

domxml_xslt_stylesheet($sectionXSL)
0,0268149375916

$domxsl->process($domxml)
0,039293050766

То есть сумма на всё это - порядка 0,128 сек. Только тут машина полностью в моём распоряжении, на реальном сервере помедленнее будет. Не знаю, конечно, но я привык к циферкам поменьше.

Впрочем, всё меркнет по сравнению с тем, сколько этот $sectionXML генерится. Всё сделано жутко неоптимально...

Это сообщение отредактировал(а) dm9 - 20.9.2005, 11:21

Я пользуюсь xml + xslt уже около года, с небольшими сайтами (информационные на своей цмске) проблем не было - только плюсы, по сравнению со смарти и sql. Однако когда я столкнулся с генирированием на одной странице нескольких кусков с разных xsl шаблонов, да еще и если xml база внушительная, скорость была работы стала просто недопустимой.

Я думаю, есть 2 выхода: разбивать xml базы на разные файлы (в одной слишком много мусора, а сам domxml() занимает больше всего времени), либо хранить все в xml sql

Почитал, подумал. Сейчас писал новый двиг под РНР 5, по сравнению с прошлой версией (под четверку), работает немного медленее, но функционал возрос, и, фактически все один сплошной ООП - от простеших функций, до выдачи результов селектов с базы в виде объектов унаследованных от интерфейса итерации.
Я долго думал, много ли это, для полнофункционального движка (без оптимизации кода правда) 0.013, и решил что это вполне допустимо (хоть и без полной нагрузки). Сейчас старый двиг вырабатывает примерно 0.08 - 0.13 при загруженности всякого рода модулями и т.п. и сложной архитектуры построения разделов.
А на счет компоновки xsl - почему не юзать динамичное подключение шаблонов? Просто добавляем необходимые фрагменты ипортируя их в XSL документ и все. Хотя может для некоторых задач и вариант с генерацией кусочками пойдет.

К сожалению, ни о чём не говорит без параметров сервера.

dm9, Semperon 2200. 512 ОЗУ.
Под FreeBSD на сервере работает в полтора раза быстрее.
Новый двиг тестирую на p4 2,8, 1GB ОЗУ.
На хостере по моему Xeon, 1,8 (вроде два), 1GB оперативки.

dm9, да, если интересно, по сравнению с данным форумом (имею ввиду сам двиг, т.е. с несколькими форумами и небольшим кол. сообщ.), то форму работает вдвое медленее

На самом деле, сравнивать сложно.

Я ориентируюсь на цифру 0.05 на средней машине разработчика (естественно, свободной от других напрягающих ЦП и диск процессов). Скажем, около 2 ГГц, 512 МБ. Иногда приходится опускаться до 0.1, хотя это уже очень медленно.

На хорошем вирт-хостинговом сервере нормальной загруженности (4 ЦП, Линукс) в этом случае получается в среднем раза в 2 меньше. Хотя, конечно, раз на раз не приходтся, если сайтов много на машине.

dm9, в таком случае у меня 0.03 на моем (загруженном процессами) Semperon 2200+. Хотя думаю до 0.5 дойдет рано или поздно. Хотя как знать.

В общем я за XML руками и ногами + за грамотность разработчиков и оптимизаторов.

Вот и скатились до мерки пиписьками... 

Странно, а почему никто не учитывает транспортных затрат, которые в большинстве случаев в разы перекрывают затраты на генерацию контента?
 

Учитываем. Но волнует не это, а загрузка сервера - раз, работа на быстром канале - два (потому что жутко напрягает ждать на хорошей выделенке 5 секунд на страницу). Именно поэтому и интересует время исполнения.

И никто не меряется, это просто сравнение. В своё время мне эти цифры очень инетресны были. А доходить пришлось до этого самому.