Третий номер журнала "Практика функционального программирования"

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

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

tailgunner (22.12.2009 15:35:02)

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

ugoday (22.12.2009 15:42:34)

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

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

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

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

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

Kuka (22.12.2009 16:09:20)

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

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

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

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

kemm (22.12.2009 17:32:16)

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

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

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

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

LamerOk (22.12.2009 19:01:28)

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

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

kemm (22.12.2009 19:44:00)

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

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

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

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

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

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

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

pitekantrop (22.12.2009 19:44:05)

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

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

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

kemm (22.12.2009 19:54:50)

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

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

pitekantrop (22.12.2009 19:55:05)

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

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

pitekantrop (22.12.2009 19:56:30)

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

Сталкиваюсь с большими (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, чтобы не потерять ценные переносы строк в полезных текстах.

chumpa (22.12.2009 19:57:08)

Улыбнуло

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

pitekantrop (22.12.2009 19:57:48)

имелся в ввиду 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>

chumpa (22.12.2009 19:59:06)

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

archimag (22.12.2009 21:37:02)

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

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

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

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

Miguel (23.12.2009 2:28:53)

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

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

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

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

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

шикарно.

ugoday (23.12.2009 10:28:17)

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

LamerOk (23.12.2009 14:35:12)

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

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

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

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

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

Кэп!

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