> Ещё раз, для альтернативно-одарённых, медленно и печально

Перестань разговаривать сам с собой, это не доведет до добра.

Прочитал как: «А ты тролль или диалектик?». Много думал.

Эка вас цепануло, пупсики. Смотрите сюда, все просто.

Парсинг: делается за один проход, затраты по памяти: дерево + данные, произвольный доступ к элементам за предсказуемое время (можно добиться гарантированного).

Ммаппинг: тот же самый проход для построения дерева и всасывания ммапнутого файла в кеш, затраты по памяти: дерево + полный XML-markup (файловому кешу ОСи пофиг на данные и не-данные внутри XML'я, он всасывает файл целиком), непредсказуемое время доступа к данным.

Итого: выпендриваясь с mmap'ом, огребаете оверхед по памяти в виде маркапа (который в XML'е может составлять хоть 100% от данных) и необходимость молиться на ОС, чтобы она ВНЕЗАПНО не выкинула половину вашего XML'я из кеша посередь расчетов. Вот и все, пупсики.

P.S. Никого не игнорирую принципиально, ибо даже самое унылое белко может, опять-таки ВНЕЗАПНО, родить неожиданный лулз.

За хранение оборачиваемых данных в гиговых масштабах в хемеэле следует убивать в любом случае, вне зависимости от того, какую систему и в какую позу это ставит.

Если же к данным обращениям эпизодические, и при этом данные в хемеэле резко доминируют надо разметкой (едиснственно вменяемый случай для развесистых хемеелей), то выбор следующий - либо делать парс целиком, либо кэшировать индекс и читать данные по требованию. Реализовывать второй вариант на цацкеле _проще_.

Альтернативно одарённые, реализующие системы с тяжёлыми преобразованиями поверх многиговых хемеэлей, никого не волнуют.

О, да. Пупсег выдумал редкий граничный случай, в котором его любимая модель представления оказывается лучше альтернативной, и рад по уши. Только вот следом прилетит следующий случай, в котором твоё DOM-дерево в имеющуюся память уже не влезет.

> Пупсег выдумал редкий граничный случай

Он вообще ничего не выдумал, в еще раз всем доставил:

произвольный доступ к элементам за предсказуемое время

непредсказуемое время доступа к данным.

Кроме того, он свято верит, что дерево в памяти занимает меньше места, чем маркап. )))

> Кроме того, он свято верит, что дерево в памяти занимает меньше места, чем маркап. )))

Ну он же придумал свой эксэмэль с блэкджеком и шлюхами, в котором разметка занимает 100%...

> Парсинг: делается за один проход, затраты по памяти: дерево + данные, произвольный доступ к элементам за предсказуемое время (можно добиться гарантированного).

Прямо реалтаймовый парсинг XML. :)

Своп отключишь?

маркапа (который в XML'е может составлять хоть 100% от данных)

А в DOM-е имена элементов и атрибутов не хранятся? Или ты видел XML на 100% состоящий из угловых скобок и отступов?

Никого не игнорирую принципиально

Звездишь. Я тебе написал, что индексы можно каждый раз не пересчитывать, а ты опять свою сказку про белого бычка начинаешь.

> Или ты видел XML на 100% состоящий из угловых скобок и отступов?

Отступы разве игнорируются? Мне казалось, что нет...

В любом случае, он именно это и сказал — xml весом в NГб, состоящий исключительно из разметки. 8))

> А в DOM-е имена элементов и атрибутов не хранятся?

Хотя, конечно, словарик будет.

> Отступы разве игнорируются? Мне казалось, что нет...

Некоторым парсерам можно сказать, чтоб они игнорировали.

кое-в-чём Кука прав

Сталкиваюсь с большими (50..200) xmlями часто, всегда там бизнес-данные и порезать их на куски не всегда возможно.

Легко может придти такое в UCS-4:

<?xml ляляля ucs-4?>
<x:resultset xmlns:x=«veryverylongurlveryverylongurlveryverylongurl»>
<y:row xmlns:y=«anotherveryverylongurlveryverylongurlveryverylongurl»>
<a>1234</a>
<b>1234</b>
<c>1234</c>
<d>1234</d>
<e>1234</e>
<f>1234</f>
</y:row>
<y:row xmlns:y=«anotherveryverylongurlveryverylongurlveryverylongurl»>
<a>1234</a>
<b>1234</b>
<c>1234</c>
<d>1234</d>
<e>1234</e>
<more:f xmlns:more=«всё не терпится»>1234</more:f>
</y:row>
</resultset>

Этот пример занимает 606 байт в однобайтовой кодировке и с выкинутыми пробелами 430 байт. Если учесть повторение неймспейсов — одна и та же хрень несколько раз — и имён тегов (которые здесь минимальны), то с полуторной разницы без потери смысла можно ужаться ещё более сильно.

Конечно, надо смотреть XSD, чтобы не потерять ценные переносы строк в полезных текстах.

Улыбнуло

http://i.imgur.com/hF6mS.jpg

имелся в ввиду xml:

<?xml ляляля ucs-4?>
<x:resultset xmlns:x=«veryverylongurlveryverylongurlveryverylongurl»>
______<y:row xmlns:y=«anotherveryverylongurlveryverylongurlveryverylongurl»>
____________<a>1234</a>
____________<b>1234</b>
____________<c>1234</c>
____________<d>1234</d>
____________<e>1234</e>
____________<f>1234</f>
______</y:row>
______<y:row xmlns:y=«anotherveryverylongurlveryverylongurlveryverylongurl»>
____________<a>1234</a>
____________<b>1234</b>
____________<c>1234</c>
____________<d>1234</d>
____________<e>1234</e>
____________<more:f xmlns:more=«всё не терпится»>1234</more:f>
______</y:row>
</resultset>

А кто-нибудь из редакции или тех «18 профессиональных программистов» собирается решать эти конкурсные задачи? Или они выше этого и будут только судить?

>> я привык к почасовой оплате.

Kuka

Мне даже подумать не ловко, о какой профессии может идти речь...

LamerOk *

ТЫ ЗНАЛ !!! :-)

М-м-м... Адвокат?

> Но дураком ты назвал только Куку :) Крепко он вас задел :D

Его пафосный бред осточертел. Он засирает кучу тем и провоцирует людей не троллинг.

P.S. для протокола - в задачах парсинга многогиговых XML-файлов не разбираюсь, и не хочу.

Вот и я про то же, человек придумал дурацкую задачу, и начинает выдумывать граничные случаи, когда эта задача будет лучше/быстрее/етц чего-либо другого. Вон он уже предлогал сделать что-то вроде mlockall/выключить своп (иначе нельзя гарантировать, что многогигабайтная DOM-модель в памяти не будет вытесненна из RAM). Не, ну не бред ли?

Да и пафосные посты, начинающиеся на «Вы не понимаете сути» - детский троллинг.

шикарно.

А главное - правильная подборка языков. Заметьте - никаких питонов и перлов. ;))

Название журнала не отражает его содержание, зато обрекает на регулярные специальные олимпиады по поводу «практичности» статей. Варианта три: (a) переименовать журнал, (b) не обращать внимания, (c) самоотверженно участвовать в специальных олимпиадах всем авторским коллективом.

По части второго номера - success stories читать дико скучно, как и вообще весь рекламный мусор типа «Ловите тренд!!!»

Задачи в третьем номере плохие (плохо сформулированы). Справедливости ради, предположения в комментариях по поводу их происхождения абсолютно неправдоподобные.

Резюме - по названию и подаче это epic fail, но тексты интересные и полезные. Хорошо бы больше статей по делу, меньше рекламы и упора на «практику» и моду.

Это не «рецензия», а мысли по поводу прочих отзывов выше.

Кэп!

Получается, ФП для программистов?