powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / XML, XSL, XPath, XQuery [игнор отключен] [закрыт для гостей] / Что быстрее ....
9 сообщений из 9, страница 1 из 1
Что быстрее ....
    #33701330
Фотография Viktor Bartel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый день,

Подскажите пожалуйста насколько быстро будет работать трансформация файла xml(размером 5 мб) в код пхп? Или лучше использовать xpath что бы извлекать параметры, которые мне нужны, сразу же в код пхп и обрабатывать их? Насколько быстро справлается xslt с обработкой больших файлов xml(>10 мб)?

Заранее вам благодарен.
--
Cordialement
Victor Bartel
...
Рейтинг: 0 / 0
Что быстрее ....
    #33701657
Фотография Viktor Bartel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так вижу что мой вопрос, вызвал затрудение у публики :). Перефразирую его, насколько быстра трансформация xslt, строится ли в памяти дерево всего xml документа при трансформаци? Или же трансформация выполняется в одном направлении пробегая документ сверху вниз? Насколько оптимально исползовать xslt с огромными файлами xml? Или более оптимально использовать sax-подобные парсеры для громозких xml файлов. Заранее вам благодарен.

--
Cordialement
Victor Bartel
...
Рейтинг: 0 / 0
Что быстрее ....
    #33701714
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
с обработкой файлов справляется не хслт а парсер.

Микрософтовский наиболее быстрый вроде (тесты где-то видел). На обычной машине трансормация 6 мб-ного файла шла где-то 20 мин. Т.е. хмл трансформировать через хсл шаблон в другой формат. Это неприемлимо для большинства систем.

В результате делал разбор через SAX без хслт, отрабатывает за несколько секунд но всю обработку писал в коде на васике
...
Рейтинг: 0 / 0
Что быстрее ....
    #33701766
Фотография Viktor Bartel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо, вы подтвердили мои сомнения, что ж придется использовать SAX для php и XmlReader для .NET ...
--
Cordialement
Victor Bartel
...
Рейтинг: 0 / 0
Что быстрее ....
    #33750632
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Перефразирую его, насколько быстра трансформация xslt, строится ли в памяти дерево всего xml документа при трансформаци?

Это зависит от типа парсера XML, используемого трансформатором (SAX или DOM). Обычно используется SAX , тогда дерево НЕ строится в памяти.

Или же трансформация выполняется в одном направлении пробегая документ сверху вниз?

Если SAX , то да.
...
Рейтинг: 0 / 0
Что быстрее ....
    #33750891
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
если sax то не получится использовать хсл. Тогда проще в текстовом файле всё хранить а не в хмл
...
Рейтинг: 0 / 0
Что быстрее ....
    #33751765
Yura Nickolaev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Про php не знаю, к сожалению, но java XSLT-Processor'ы (Xalan, Saxon) не парсят xml в DOM при трансформации, соответственно указанные объемы могут перелопатить довольно быстро (тут больше, на мой взгляд, зависит собственно от xsl-преобразования, т.е. оно само по себе может быть написано неэффективно)
...
Рейтинг: 0 / 0
Что быстрее ....
    #33751901
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
и саксон и ксалан судя по документации парсят в дом.

SAX это Simple API for XML, по сути просто считывание файла сверху вниз и вызывание пользовательской функции на каждый нод/атрибут. Никакого хсл
...
Рейтинг: 0 / 0
Что быстрее ....
    #33752054
Yura Nickolaev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
1024и саксон и ксалан судя по документации парсят в дом.


Наличие класса
Код: plaintext
javax.xml.transform.sax.SAXSource
в Xalan и Saxon ни о чем Вам не говорит? Да, есть и DOMSource, но это не отменяет возможности НЕ строить DOM

Вот еще цитатка из документации на Saxon (старый, правда)
The SAXON API: comparison with SAX and DOM
There are two standard APIs for processing XML documents: the SAX interface, and the DOM. SAX (see http://www.megginson.com/SAX/index.html) is an event-driven interface in which the parser reports things such as start and end tags to the application as they are encountered, while the Document Object Model (DOM) (see http://www.w3.org/dom is a navigational interface in which the application can roam over the document in memory by following relationships between its nodes. Another API, JDOM, is similar in concept to DOM but provides a lighter-weight API that is more closely integrated with the standard Java 2 classes.

SAXON offers a higher-level processing model than either SAX or DOM. It allows applications to be written using a rule-based design pattern, in which your application consists of a set of rules of the form "when this condition is encountered, do this processing". It is an event-condition-action model in which the events are the syntactic constructs of XML, the conditions are XSLT-compatible patterns, and the actions are Java methods. Further, the action taken when these rules are fired may include evaaluation of XPath expressions, providing a higher-level access mechanism than raw navigation of the tree.

If you are familiar with SAX, some of the differences in SAXON are:

You can provide a separate handler for each element type (or other node), making your application more modular
SAXON supplies context information to your application, so you can find out, for example, the parent element of the one you are currently processing
SAXON provides facilities for organizing the output of your application, allowing you to direct different parts of the output to different files. SAXON is a particularly convenient tool for splitting a large document into page-sized chunks for viewing, or into individual records for storing in a relational or object database.
SAXON allows you to register your preferred SAX-compliant XML parser; you do not need to hard-code the name of the parser into your application or supply it each time on the command line. SAXON also works with several DOM implementations.
SAXON extends the SAX InputSource class allowing you to specify a file name as the source of input.
1024
SAX это Simple API for XML, по сути просто считывание файла сверху вниз и вызывание пользовательской функции на каждый нод/атрибут. Никакого хсл
Спасибо, я тоже знаю, что 2*2=4
...
Рейтинг: 0 / 0
9 сообщений из 9, страница 1 из 1
Форумы / XML, XSL, XPath, XQuery [игнор отключен] [закрыт для гостей] / Что быстрее ....
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]