Проект "CachedBuffers"

← →
DevilDevil © (2013-03-11 19:59) [0]

CachedBuffers - это удобная и быстрая библиотека, предназначенная для задач потокового чтения/записи данных.

Предположим следующую ситуацию. Существует софт который генерирует очень большие объёмы данных, допустим 15млн ячеек, и сохраняет это всё в *.xlsx файл размером 100Мб. Ваши бухгалтера пытаются обрабатывать этот файл Excel-ем, но Excel жутко тормозит, и поэтому вам поручили разработать приложение, которое на вход будет принимать данный файл, обрабатывать своими алгоритмами, и на выходе выдавать какой-то результат. Благо *.xlsx файл это всего лишь Zip + набор Xml.

И здесь начинаются сложности. Даже не в распаковке Zip и не в парсинге Xml, а в объёмах. Zip-архив размером 100Мб, содержащий Xml файлы, вполне может распаковаться в 1Гб. И хранение/обработка всего этого в ОЗУ отрицательно сказывается на производительности, потому что бухгалтера работают на 4х пентиумах с 1Гб оперативы, и обновления парка машин ваш директор не планирует, потому что и на этих машинах Word, Excel и Outlook прекрасно работают. В таких задачах необходимо читать и обрабатывать данные кусками. Получится множественная последовательная обработка данных:
Обработка данных <-- XML в нужной кодировке <-- XML в исходной кодировке <-- Zip данные <-- Файл

Сложно производить преобразования, но не менее сложно производить менеджмент "кусков памяти". Поэтому я решил написать библиотечку, которая избавит меня от рутины менеджмента памяти и позволит напрямую удобно обращаться к ней, чтобы достичь хорошей производительности. Назвал я эту библиотечку "CachedBuffers": https://sourceforge.net/projects/cachedbuffers/

Интерфейс немного похож на TStream, но отличается производительностью и возможностью прямого доступа к буферной памяти. Отказался от классов в пользу object-ов потому что это благоприятно сказывается на производительности на уровне машинного кода.

Кстати библиотека содержит так же интерфейсы специально заточенные под чтение и запись файлов. Хочу поблагодарить людей, которые участвовали в тестировании нескольких утилит, с целью выявления оптимальных размеров буферов и набора атрибутов для файлов в операционной системе Windows: O"ShinW, Владислав, dmk, Jeer, DVM, Sapersky, Игорь Шевченко, megavoid, Inovet, Rouse_, Труп Васи Доброго, kipar, RenGD, Dronas, antonn, X11, Anton R, DimaBr.

Эту библиотеку я выкладываю по трём причинам:
1) Я сторонник позиции, что надо делать больше добрых дел. Это здорово пользоваться и делиться бесплатными библиотеками.
2) Лишний раз сообщить, что когда дойдут руки - буду заниматься проектом ApolloXML: http://delphimaster.net/view/15-1359703096/
По прежнему нет главного чувака, который писал бы утилиту и разобрался с XSD
3) Надеюсь библиотека пройдёт путь тестирования и оптимизации под x64, FPC, C++Builder, iOS, MacOS, Android, KOL, Linux. Поэтому если вы заинтересованы - вкладывайте силы в разработку

Спасибо за внимание

← →
DevilDevil © (2013-03-11 20:07) [1]

* ApolloXML будет основываться на CachedBuffers

← →
LivedLived (2013-03-11 20:07) [2]

Удалено модератором
Примечание: Не в пивной...

← →
DevilDevil © (2013-03-11 20:11) [3]

Удалено модератором

← →
DevilDevil © (2013-03-11 20:12) [4]

да и не в Excel-е дело, если тут кто-то не понял ))))

← →
Rouse_ © (2013-03-11 20:13) [5]

> DevilDevil © (11.03.13 20:07) [1]
> * ApolloXML будет основываться на CachedBuffers

О, ты решил нормальный быстрый парсер писать? Это дело здравое, всеми руками-ногами за, сам такое хотел делать (у нас как раз в некоторых местах просадка на парсинге XML), но начальство тормознуло когда прикинули объем времязатрат.
Только сразу пожелание - ты его сразу с поддержкой юникода делай, ибо со старыми известными мне парсерами проблема именно в этом была, слишком сложно все перекинуть на 2010 и выше.

← →
LivedLived (2013-03-11 20:19) [6]

Удалено модератором
Примечание: Не в пивной...

← →
Rouse_ © (2013-03-11 20:22) [7]

А кстати еще один момент посоветую (по крайней мере я когда приступал к проектировании задачи смотрел именно в эту сторону).
Если ты сделаешь свой парсер с поддержкой стандартных интерфейсов IXMLDocument/IXMLNode etc то, с учетом что большинство использует именно данный штатный механизм, подключение парсера, с поддержкой уже готового принципа работы с данными, минимальная по трудоемкости задача.
Делается такая поддержка сом понимаешь тривиально, просто твои обьекты реализуют все методы данных интерфейсов и собственно все, а логика уже внутри.

← →
DevilDevil © (2013-03-11 20:23) [8]

> Rouse_ © (11.03.13 20:13) [5]

розыч, возьми быстрые С++ SAX парсеры и запакуй в dll, потому что ещё неизвестно когда у меня руки дойдут, да и работать будет на основе XSD, да и завишу я от других людей, одному не потянуть проект.

могу посоветовать Expat
если файлы не очень большие, то может подойти PugiXML

← →
Rouse_ © (2013-03-11 20:26) [9]

> DevilDevil © (11.03.13 20:23) [8]
> > Rouse_ © (11.03.13 20:13) [5]
>
> розыч, возьми быстрые С++ SAX парсеры и запакуй в dl

Да я решение то нашел - временное. Пока хватает, а вот на будущее... У тебя вроде слова с делом не расходятся, поэтому и советую :)

← →
Jeer © (2013-03-11 20:27) [10]

Удалено модератором

← →
DevilDevil © (2013-03-11 20:29) [11]

> Rouse_ © (11.03.13 20:22) [7]
> IXMLDocument/IXMLNode etc

во-первых, это DOM.
во-вторых, интерфейсы

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

у меня задача выжать вообще самые соки, чтобы летало + несколько приятностей типа валидации и т.д.

← →
Rouse_ © (2013-03-11 20:32) [12]

> DevilDevil © (11.03.13 20:29) [11]
> во-первых, это DOM.

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

← →
DevilDevil © (2013-03-11 20:33) [13]

Удалено модератором

← →
DevilDevil © (2013-03-11 20:33) [14]

Удалено модератором

← →
Rouse_ © (2013-03-11 20:37) [15]

Удалено модератором

← →
картман © (2013-03-11 20:38) [16]

"Но я же могу рассуждать о качестве омлета, хотя еще ни разу не снес ни одного яйца."(с)

← →
Inovet © (2013-03-11 20:41) [17]

Удалено модератором

← →
DevilDevil © (2013-03-11 20:43) [18]

Удалено модератором

← →
Ega23 © (2013-03-11 20:45) [19]

> во-первых, это DOM.
> во-вторых, интерфейсы

С одной стороны - да. С другой - именно это и используется. Я не встречал кода, где метод XMLSave в качестве входного параметра использовал бы TXMLNode, везде IXMLNode.
Тут уже вопрос в той самой пресловутой целесообразности: либо меняем всё на стороннюю реализацию TXMLNode, либо жертвуем производительностью, но избегаем работы по переводу "сотни тонн" кода на новый лад (и, тем самым, избегаем кучи ошибок, которые обязательно появятся).

← →
DevilDevil © (2013-03-11 20:47) [20]

> Ega23 © (11.03.13 20:45) [19]

открой для себя XML SAX
встретишь много нового

← →
Rouse_ © (2013-03-11 20:54) [21]

> DevilDevil © (11.03.13 20:47) [20]
> > Ega23 © (11.03.13 20:45) [19]
>
> открой для себя XML SAX
> встретишь много нового

Ничего он не встретит, мы с ним проект по реализации XML парсера и прорабатывали и SAX по понятным причинам не подошел :)
Не злись на всех подряд :)

← →
Rouse_ © (2013-03-11 20:57) [22]

ЗЫ: собственно именно под мою идеологию совместимости тебе Легыч и говорит.

← →
Inovet © (2013-03-11 20:57) [23]

Удалено модератором

← →
Rouse_ © (2013-03-11 21:01) [24]

Удалено модератором

← →
Ega23 © (2013-03-11 21:34) [25]

Удалено модератором

← →
Jeer © (2013-03-11 21:34) [26]

Удалено модератором

← →
Германн © (2013-03-11 21:50) [27]

Удалено модератором

← →
картман © (2013-03-11 22:06) [28]

Удалено модератором

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

у меня задача выжать вообще самые соки, чтобы летало + несколько приятностей типа валидации и т.д.

А что насчет реальных (не тобой подсунутых) данных?
Например когда для правильной обработки какого-то узла требуется доступ к другим узлам от которых зависит интерпретация текуще захваченного саксом узла?

Удалено модератором

> Например когда для правильной обработки какого-то узла требуется
> доступ к другим узлам от которых зависит интерпретация текуще
> захваченного саксом узла?

у тебя есть какие-нибудь предположения на тему, зачем существуют SAX-парсеры если есть DOM ?

Запасаемся попкорном

у тебя есть какие-нибудь предположения на тему, зачем существуют SAX-парсеры если есть DOM ?

Вопрос не понял?
Тогда еще раз:

А что насчет реальных (не тобой подсунутых) данных? .... и далее по тексту.

> Медвежонок Пятачок © (11.03.13 22:45) [33]

а что будет если в мавзолей ленина засунуть сталина ?
я тоже не понимаю смысла твоего вопроса

Удалено модератором

"такой простой вопрос, а ставит вас в тупик"

Так что там насчет реальных данных-то?

> Так что там насчет реальных данных-то?

а для каких данных я по твоему собираюсь разрабатывать быстрый парсер ?
для синтетических ?
он должен выдавать какой-то фейковый результат ?

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

как оно будет работать?
если узел item - иногда это лопаты, а иногда - дровосеки. причем в одном и том же документе.

а давай сначала ты ответишь, а потом уже твой вопрос рассмотрим?

Проект "CachedBuffers" Найти похожие ветки