|
|
|
Производительность при работе с xml
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! как-то странно получается.. вобщем нужно выводить на aspx страницу куски из html файла ( PlaceHolder1.Controls.Add(New LiteralControl ..... ). при получении кода из хтмл файла вот таким образом: XHTML = IO.File.ReadAllText(Server.MapPath("~/" +ts1+".htm")), System.Text.Encoding.GetEncoding("windows-1251")) время выполнения около 0,01332... Если же начинаю вытаскивать из хтмля куски с помощью System.Xml.XmlDocument или XmlDataSource , то время выполнения возрастает до 4,3905407 вот пример кода, из-за которого возрасло время выполнения: XHTML = IO.File.ReadAllText(Server.MapPath("~/" +ts1+".htm")), System.Text.Encoding.GetEncoding("windows-1251")) Dim nl As System.Xml.XmlNodeList Dim n As System.Xml.XmlNode Dim zz As New XmlDataSource 'отсюда начинается увеличение времени zz.Data = XHTML nl = zz.GetXmlDocument.GetElementsByTagName("title") For Each n In nl Title = n.InnerText Next вроде копейки весит.... ну я понимаю, если бы время возрасло на незначительную величину, но не на 4 же с..... кстати, а вот html код, который подгружаю: <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>test</title> </head> <body > </body> </html> что посоветуете??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 14:27 |
|
||
|
Производительность при работе с xml
|
|||
|---|---|---|---|
|
#18+
да никто тебе ничего не посоветует тормозная это технология до самой жопы как и везде - 99% раскрутки этой технологии - ЧИСТЕЙШАЯ РЕКЛАМА именно по этому был например придуман заменитель XML- JSON всех зачистим и замочим, а кто спрячется - персонального доктора вышлем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 16:47 |
|
||
|
Производительность при работе с xml
|
|||
|---|---|---|---|
|
#18+
урка1да никто тебе ничего не посоветует тормозная это технология до самой жопы как и везде - 99% раскрутки этой технологии - ЧИСТЕЙШАЯ РЕКЛАМА именно по этому был например придуман заменитель XML- JSON всех зачистим и замочим, а кто спрячется - персонального доктора вышлем Отличный совет и решение проблемы! Наверняка в твоем случае хватит функционала класса XmlReader (цитата из МСДН "Represents a reader that provides fast, non-cached, forward-only access to XML data.") ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 16:54 |
|
||
|
Производительность при работе с xml
|
|||
|---|---|---|---|
|
#18+
урка1 заменитель XML- JSON слов нет... Вот когда обрастет этот заменитель функционалом XML, тогда и посмотрим, что там за скорость будет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 17:04 |
|
||
|
Производительность при работе с xml
|
|||
|---|---|---|---|
|
#18+
да, совет ОТЛИЧНЫЙ - потому что не чтении гавнасофтовских буквариков основан - а НА ПРАКТИЧЕСКОЙ работе с XML и могу свой совет вопрошающему еще раз повторить - это САМАЯ тормозная из известных технологий сериализации поэтому жалобы на ее тормознутость ЕСТЕСТВЕННЫ и никак непреодолимы всех зачистим и замочим, а кто спрячется - персонального доктора вышлем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 17:21 |
|
||
|
Производительность при работе с xml
|
|||
|---|---|---|---|
|
#18+
урка1да, совет ОТЛИЧНЫЙ - потому что не чтении гавнасофтовских буквариков основан - а НА ПРАКТИЧЕСКОЙ работе с XML и могу свой совет вопрошающему еще раз повторить - это САМАЯ тормозная из известных технологий сериализации поэтому жалобы на ее тормознутость ЕСТЕСТВЕННЫ и никак непреодолимы всех зачистим и замочим, а кто спрячется - персонального доктора вышлем При чем тут сериализация? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 17:22 |
|
||
|
Производительность при работе с xml
|
|||
|---|---|---|---|
|
#18+
ConfigXmlDocument работает быстро ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2009, 20:41 |
|
||
|
Производительность при работе с xml
|
|||
|---|---|---|---|
|
#18+
урка1...XML- JSON... +1 Я именно такой штукой и пользуюсь. Другое дело, что это - совсем не аспнет (хе-хе). Действительно, всех нафиг зачистим! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2009, 21:11 |
|
||
|
Производительность при работе с xml
|
|||
|---|---|---|---|
|
#18+
вот млин!!!!! тема очень интересно раскрылась... добавил к хтмл доку строчку <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> время выполнения 4,25 удвлил-выполнения 0 почему? кто знает? ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2009, 22:46 |
|
||
|
Производительность при работе с xml
|
|||
|---|---|---|---|
|
#18+
урка1тормозная это технология до самой жопы как и везде - 99% раскрутки этой технологии - ЧИСТЕЙШАЯ РЕКЛАМА именно по этому был например придуман заменитель XML- JSON урка1 , довелось ли вам находить куски кода в библиотеках разбора XML, создающие тормоза при работе с XML-документами? Мне вот довелось. И во многих библиотеках, в основе которых лежит разбор XML. По этой причине выбрал библиотеку CWXML. Чтоб вы понимали почему, скажу, что её разработчик применяет свою библиотеку для обращения с геоданными. И ещё он сделал формат для бинарной укладки XML-данных, что довольно хорошо сжимает их без всякого архивирования и обеспечивает при этом прямой доступ со значительным сокращением времени разбора. Камень преткновения почти всех известных библиотек разбора XML -- лексический анализатор. Если посмотреть его код, то увидим тупой swtich (case) по текущему символу. Если компилятор не совсем хороший, то получаем линейную сложность поиска действия в зависимости от текущего символа. Если компилятор умеет оптимизировать switch, получаем логарифмическую или константную сложность. Этим грешат библиотеки Apache (Xerces XML), libxml, libxml2, libexpat и много ещё каких, чей код мне довелось проанализировать, когда выбирал XML-библиотеку. А если парсер XML сделан не на C++ или C, то вероятность оптимизации swtich при компиляции стремится к нулю. И поэтому ваши наблюдения про время операций над XML-документами, по большей части, оказываются верные на практике. Вторая проблема этих библиотек и их применения в конечном приложении -- что они грузят весь поток символов в оперативную память, затем полностью его разбирают, и только потом выполняют запрос пользователя к XML-данным. Добавим сюда время на создание объектов в оперативной памяти, инициализацию COM, переключения контекстов между процессами (в случае Windows и COM, а значит -- VBA, ASPX), переключение контекстов в процессе между управляемым и неуправляемы кодом (в случае .NET), задержки на маршалинг данных (Windows, COM), задержки на выполнение интерпретируемого кода (в случае JavaScript, JScript, VBScript, Python, Perl, Java и т.д.) и получим в точности то, что наблюдаете не только вы. А ещё неаккуратный пользователь может включить (или не знать, что нужно выключить некоторые умолчания) проверку XML-документа (на синтаксис, на сущности или даже на схему данных). И это может привести к запросам к другим серверам в Интернете и последующему разбору самих определений, затем -- к проверке соответствия им XML-документа. Иногда это необходимо, чтобы не пустить мусор в систему. Иногда -- нет. Зависит от задачи. Итого, проблема не в XML, а в реализации операций над ним. Потому что эти операции можно эффективно реализовать только в том случае, если применять наиболее совершенные методы, разрабатываемые в теории компиляторов и формальных языков, и приёмы программирования для превращения линейного (или хуже) времени доступа в константный (а это уже про теорию поиска и сортировки). Ну и всё это замешано на подавляющем отторжении какой-либо теории вообще ("это ведь думать надо"). Есть альтернатива -- потоковая обработка XML-документа (вместо полной загрузки и разбора), предусмотренная самой концепцией и конструкцией XML. Обработать XML-документ размером от 20ГБ с таким подходом совершенно реально разово минут за 20 на одном CPU 2.4 ГГц. Время обработки зависит от количества извлекаемых элементов XML. Если бы не кривая реализация Google принципа "The same origin policy" в Google Chrome (в отличие от Mozilla Firefox, Opera или IE), тогда можно было бы на клиенте использовать XSLT для получения из XML любого нужного HTML или иного текста напрямую без выполнения JavaScript-кода по каждой детали. Соответственно, скорость кратно выше, а нагрузка на сервера многократно ниже, т.к. это трансформация происходит на клиенте. Т.е. имеем намеренное создание условий самим Google для продвижения JavaScript (т.е. их node-js) путём создания значительных трудностей или критических блокирующих условий при использовании XML-трансформаций на клиенте. Хотя декларативный язык (XML, HTML, CSS) даёт априори бОльшую безопасность, чем процедурный (типа JavaScript). Когда JSON будет способен передавать такой же объём данных и метаданных, тогда у него начнутся ровно те же (если не бОльшие) проблемы в силу принципа Дирихле (в n коробок можно разместить не более n объектов, каждый из которых оставляет в коробоке места меньше целого объекта -- это формулировка для программистов). Этот принцип тут при том, что количество символов в потоке будет не сильно меньше (а даже больше). И ещё, учитывая синтаксические особенности JSON, возникнут задержки на интерпретацию роли прочитанного значения (чтобы определить, это данные или метаданные). Далее, учитывая, что JSON часто разбирается и интерпретируется в JavaScript самим интерпретатором скрипта, получаем сложность, не ниже eval от такого объёма кода. А если интерпретируется самим кодом на JavaScript, то получаем все те задержки, что перечислены выше. Для проверки можете сравнить время разбора эквивалентного JSON-документа (эквивалентность -- значит и по данным, и по метаданным) размером от 10 МБ исходного XML-документа. И в Oracle Database, и в MS SQL Server есть технология прямой конвертации XML-документа в табличное представление. И она работает куда быстрее, чем какие-либо JSON->MySQL. Последний даже рядом не лежал, когда размеры XML-документов начинаются от 5 МБ. Потому что промежуточный слой, конвертирующий JSON-документ в табличное представление, даёт основную задержку на трансформацию и вставку данных в БД. Это я говорю из опыта реализации синхронизаторов с автоматическим разрешением конфликтов и контролем версий данных для распределённых систем. Ну т.е. не тупая репликация или зеркалирование, а создание прозрачной (для пользователя) инфосреды по операциям чтения и изменения данных с возможностью повторения отменённых операций. Сложность модели данных -- от 40 таблиц по 100 и более колонок, или от 100 классов объектов. Разумеется, используются дельты между состояниями, а не целые снимки состояний систем. Итого, торомознутость лежит не в XML-технологии, а в библиотеках для работы с XML-документами, и в тактике применения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2020, 02:58 |
|
||
|
Производительность при работе с xml
|
|||
|---|---|---|---|
|
#18+
Алексей Ф. Вторая проблема этих библиотек и их применения в конечном приложении -- что они грузят весь поток символов в оперативную память открой для себя SAX-reader ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2020, 11:51 |
|
||
|
Производительность при работе с xml
|
|||
|---|---|---|---|
|
#18+
Алексей Ф. урка1 , довелось ли вам находить куски кода Вы реально считаете, что неплохо бы спросить юзера урка1 через 11 лет об хмл? И внимательно почитать его ответы, если они будут и он еще есть? Не, ну, всякое бывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2020, 08:28 |
|
||
|
Производительность при работе с xml
|
|||
|---|---|---|---|
|
#18+
Изопропил, Изопропилоткрой для себя SAX-reader 1. себе открой глазаАлексей Ф.Есть альтернатива -- потоковая обработка XML-документа (вместо полной загрузки и разбора), предусмотренная самой концепцией и конструкцией XML.SAX-reader -- лишь один из методов потоковой обработки. 2. и начни уже понимать написанное: Алексей Ф.Вторая проблема этих библиотек и их применения в конечном приложенииЕсли речь о библиотеках, использующих библиотеки для работы с XML, то открывать SAX-reader необходимо не мне, а пользователям тех библиотек. Потому что потом приходится использовать эти промежуточные библиотеки без SAX и без потоковой обработки вообще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2020, 19:00 |
|
||
|
Производительность при работе с xml
|
|||
|---|---|---|---|
|
#18+
Ролг Хупин, 1. Считаете, что разобранные вопросы перестанут быть актуальными через 10 лет, если они столь же актуальны на данный момент? 2. Полно народу, кто в вопросах урка1 увидит и свои вопросы тоже. А значит в их разборе увидит, куда копать и что применять, чтобы решить. На свете не только вы или урка1 . И время значения не имеет: это не сиюминутный трёп в чатике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2020, 19:06 |
|
||
|
|
start [/forum/topic.php?fid=18&msg=39944637&tid=1354750]: |
0ms |
get settings: |
12ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
34ms |
get topic data: |
13ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
| others: | 271ms |
| total: | 419ms |
| 0 / 0 |
