← All posts tagged XML

agr
изоляция XML погроммирование дыбр по следам #2921103:
— во-первых, переводить текст Никиты на хабре — это LOL
— во-вторых, шёл 2018-й год, а люди до сих пор мучаются открывать и читать большие (0.5G+) файлы редакторами (в комментах 200M, блин, те же вим и емакс легко справляются с этим, правда у них тоже есть разумный предел — на моей памяти у емакса — 1.5G, у вима — 2G — ну т.е. открывает, но ходить по файлу уже неприятно).
— далее, камушек в свой огород. брался написать анализатор XML как-то и, как водится, не довёл эту активность до конца. каюсь, грешен. интересно, подобный софт всё ещё нужен кому-то, кроме моего бывшего работодателя?!
agr
XML sax Win Haskell По итогам проведения разных тестов в #2808429 над XML 3.5 ГБ (one-line) или 4 ГБ (pretty-printed): Haskell вполне годится для потоковой обработки XML.
Тесты производились с помощью tagsoup + fast-tagsoup на ручной нарезке ленивых ByteString на чанки размером ~20 МБ (так, чтобы не разрезать события SAX парсинга).

Это Win!

Следите за ленью, юзайте beautiful folds (https://hackage.haskell.org/package/folds-0.6.3) и будет вам счастье!

Ухожу в подполье.
agr
XML sax Haskell XML SAX Parser.
Lazy ByteString хорошо, но долго.
Добавляем туда замечательных фолдов, просто считаем число событий, максимально не ленясь. Для начала.
Итого 1035 секунд на 3.5 ГБ.
Strict ByteString хорошо, но сразу не хватает памяти.
Думаю, раз такое дело, то стоит дробить Strict ByteString на куски определенного размера +- несколько десятков байт на то, чтобы гарантированно попасть на границу событий. И затем передавать вычисленный аккумулятор дальше по списку.
Думаю, так оно быстрее выйдет.