Проект "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]

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

← →
Медвежонок Пятачок © (2013-03-11 22:11) [29]

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

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

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

← →
Jeer © (2013-03-11 22:13) [30]

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

← →
DevilDevil © (2013-03-11 22:30) [31]

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

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

← →
Игорь Шевченко © (2013-03-11 22:34) [32]

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

← →
Медвежонок Пятачок © (2013-03-11 22:45) [33]

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

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

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

← →
DevilDevil © (2013-03-11 22:49) [34]

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

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

← →
Ega23 © (2013-03-11 22:52) [35]

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

← →
Медвежонок Пятачок © (2013-03-11 22:54) [36]

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

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

← →
DevilDevil © (2013-03-11 23:02) [37]

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

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

← →
Медвежонок Пятачок © (2013-03-11 23:09) [38]

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

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

← →
DevilDevil © (2013-03-11 23:10) [39]

> Медвежонок Пятачок © (11.03.13 23:09) [38]

а как бы ты с такой задачей справился, используя SAX-парсер ?

← →
Медвежонок Пятачок © (2013-03-11 23:13) [40]

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

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

> Медвежонок Пятачок © (11.03.13 23:13) [40]

мне лень писать
всё точно так же как в случае SAX, только удобнее

← →
Медвежонок Пятачок © (2013-03-11 23:23) [42]

всё точно так же как в случае SAX,

А! Ну вот теперь понятно.
То есть вариантов два:

1. просто облажаться.
2. обложить парсер снаружи сотней - другой глобальных переменных-флагов и таки распарсить пусть небольшой но документ из реального мира килобайт на пятьсот.

← →
Jeer © (2013-03-11 23:27) [43]

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

← →
DevilDevil © (2013-03-11 23:28) [44]

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

ну это каждый сам решает как поступать :)

← →
Jeer © (2013-03-11 23:34) [45]

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

← →
DevilDevil © (2013-03-11 23:40) [46]

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

← →
Jeer © (2013-03-12 00:03) [47]

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

← →
DevilDevil © (2013-03-12 00:11) [48]

Удалено модератором
Примечание: Смени тон

← →
DevilDevil © (2013-03-12 00:18) [49]

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

← →
Kerk © (2013-03-12 00:23) [50]

Мне вот здесь обсуждение понравилось: http://www.gamedev.ru/flame/forum/?id=173923

А вообще скучные времена настали, на какой форум не зайдешь, всюду над одним и тем же лицом глумятся.

← →
Kerk © (2013-03-12 00:24) [51]

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

← →
DevilDevil © (2013-03-12 00:25) [52]

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

← →
Kerk © (2013-03-12 00:28) [53]

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

← →
DevilDevil © (2013-03-12 00:29) [54]

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

← →
DevilDevil © (2013-03-12 00:33) [55]

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

← →
Jeer © (2013-03-12 00:40) [56]

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

← →
Jeer © (2013-03-12 00:42) [57]

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

← →
Kerk © (2013-03-12 00:42) [58]

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

← →
Kerk © (2013-03-12 00:43) [59]

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

← →
DevilDevil © (2013-03-12 00:44) [60]

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

← →
DevilDevil © (2013-03-12 00:48) [61]

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

← →
Kerk © (2013-03-12 00:54) [62]

Нет, спасибо. Тебя и так почти на всех форумах, где я бываю, предостаточно. И на всех этих форумах у тебя репутация клоуна. И что самое забавное, никаких выводов ты не делаешь. Ну конечно же, это все никчемные завистники. Поголовно.

← →
Kerk © (2013-03-12 00:54) [63]

Ладно, я спать пошел, а тебе еще на десятке форумов самоутверждаться. Удачной ночной смены.

← →
DevilDevil © (2013-03-12 00:58) [64]

> Kerk © (12.03.13 00:54) [62]
> Ну конечно же, это все никчемные завистники. Поголовно.

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

← →
картман © (2013-03-12 01:20) [65]

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

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

← →
DevilDevil © (2013-03-12 01:22) [66]

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

← →
картман © (2013-03-12 01:33) [67]

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

← →
Германн © (2013-03-12 01:42) [68]

> DevilDevil ©

Я бы на твоём месте задумался над вопросом - "Почему мои ветки столь часто раскрашиваются красным цветом? Хотя в них нет ни политики ни футбола?".

← →
DevilDevil © (2013-03-12 01:51) [69]

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

← →
DevilDevil © (2013-03-12 01:51) [70]

> картман © (12.03.13 01:33) [67]

кстати что если не секрет ?

← →
Sapersky (2013-03-12 02:00) [71]

> DevilDevil
На геймдеве те ещё тролли, конечно, но и ты хорош. До тебя там пытались донести то, о чём я говорил минимум 2 раза: чтобы тесты чтения были в равных условиях, надо сбрасывать перед каждым тестом дисковый кэш. Иначе получается, что результаты зависят от порядка тестов (у первого хуже, у последующих лучше).
И я писал как сбрасывать, смотри ветку с тестами...

← →
DevilDevil © (2013-03-12 02:04) [72]

> Sapersky (12.03.13 02:00) [71]

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

а здесь - первый тест всёравно идёт через TStringList, там мизерная скорость

но опять таки - я не против коррективов тестов. говорите как - я подправлю

← →
Германн © (2013-03-12 02:07) [73]

> DevilDevil © (12.03.13 01:51) [69]
>
> > Германн © (12.03.13 01:42) [68]
>
> я чё спрашивать ?
>

И да и нет.

> потому что я отвечаю грубостью на грубость

Но сначала ты провоцируешь эту грубость.

← →
DevilDevil © (2013-03-12 02:11) [74]

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

← →
Sapersky (2013-03-12 02:16) [75]

> первый тест всёравно идёт через TStringList, там мизерная скорость

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

← →
картман © (2013-03-12 02:18) [76]

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

← →
DevilDevil © (2013-03-12 02:21) [77]

> Sapersky (12.03.13 02:16) [75]

там перед CachedReader другой сравнимый по скорости Reader, поэтому они примерно в одинаковых условиях
в целом опять таки - говори как надо - я поправлю

← →
DevilDevil © (2013-03-12 02:23) [78]

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

← →
Sapersky (2013-03-12 02:28) [79]

Перед каждым тестом открыть файл с NO_BUFFERING, закрыть, прогнать тест.

← →
Германн © (2013-03-12 02:34) [80]

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

← →
Sapersky (2013-03-12 02:56) [81]

> Перед каждым тестом открыть файл с NO_BUFFERING, закрыть, прогнать тест.

procedure ClearCache; Var h : THandle; begin h := CreateFile(PChar(FILE_NAME), GENERIC_READ, FILE_SHARE_READ, nil, OPEN_EXISTING, FILE_FLAG_NO_BUFFERING, 0); FileClose(h); end; // Run benchmark procs ConsoleWrite("Let""s test methods (it may take a few minutes):", []); ClearCache; RunBenchmarkProc("Standard TStringList reader", StringListReader); ClearCache; RunBenchmarkProc("Fast buffering reader", FastBufferingReader); ClearCache; RunBenchmarkProc("Using CachedFileReader", CachedFileReader);

← →
картман © (2013-03-12 04:23) [82]

> DevilDevil © (12.03.13 02:23) [78]
>
> > картман © (12.03.13 02:18) [76]
> > во-первых, я тебе пытаюсь донести
>
> чтобы пытаться что-то донести - нужно сначала обладать информацией

Я ею не обладаю. Более чем.

← →
DevilDevil © (2013-03-12 09:43) [83]

> Sapersky (12.03.13 02:56) [81]

перезалил бенчмарки и скриншот
спасибо
http://sourceforge.net/projects/cachedbuffers/

← →
DevilDevil © (2013-03-12 09:46) [84]

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

← →
DevilDevil © (2013-03-12 09:47) [85]

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

← →
Игорь Шевченко © (2013-03-12 10:02) [86]

Предлагаю придерживаться конструктивного русла в дискуссии

← →
DevilDevil © (2013-03-12 10:04) [87]

> Игорь Шевченко © (12.03.13 10:02) [86]

целиком и полностью за

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

кстати кому интересны какие-то сравнительные тесты:
http://www.gamedev.ru/flame/forum/?id=173923&page=7#m97

← →
никому (2013-03-12 11:58) [89]

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

← →
DevilDevil © (2013-03-12 12:01) [90]

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

← →
никому (2013-03-12 12:13) [91]

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

← →
DevilDevil © (2013-03-12 12:21) [92]

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

← →
Лукошко (2013-03-12 12:49) [93]

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

← →
Игорь Шевченко © (2013-03-12 13:48) [94]

за 20 минут написал суммирование чисел из текстового файла, которое по скорости (без оптимизации) немного уступает самому быстрому из способов автора.

Код чуть меньше 30 строк.

The benchmark shows how quickly you can read/parse files Testing file is "correct_file.txt" (about 100Mb) Total sum of numbers must be equal 0x2904E86C0 Let"s test methods (it may take a few minutes): 1) "Standard TStringList reader"... 4047ms 2) "Fast buffering reader"... 625ms 3) "Using CachedFileReader"... 453ms 4) "Mapped file reader"... 531ms Press Enter to quit

function MappedFileReader: int64;
var
Mapper: TFileMapper;
Cursor: PAnsiChar;
Number: Integer;
begin
Result := 0;
Number := 0;
Mapper := TFileMapper.Create(FILE_NAME);
try
Cursor := Mapper.Map;
while Cursor < Mapper.EndMap do
begin
if Cursor^ in ["0".."9"] then
Number := Number * 10 + (Ord(Cursor^) - Ord("0"))
else if Number <> 0 then
begin
Inc(Result, Number);
Number := 0;
end;
Inc(Cursor);
end;
if Number <> 0 then
Inc(Result, Number);
finally
Mapper.Free;
end;
end;

← →
Inovet © (2013-03-12 14:22) [95]

> [94] Игорь Шевченко © (12.03.13 13:48)
> немного уступает самому быстрому из способов автора.

Ты плохой программист, ничего не можешь и не понимаешь.

← →
Игорь Шевченко © (2013-03-12 14:33) [96]

Inovet © (12.03.13 14:22) [95]

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

Курт Воннегут, "Утопия 14"

← →
DevilDevil © (2013-03-12 14:45) [97]

> Игорь Шевченко © (12.03.13 13:48) [94]

да, у меня были опыты с MappedFile
но
1) мой подход не уступает, а судя по бенчмарку опережает на 15%
2) они имеют ограничения на размер и не позволят обрабатывать файлы в несколько гигабайт
3) мне нужен был универсальный подход потоковой обработки данных, не завязываясь лишь на файлы в ОС Windows

← →
Ega23 © (2013-03-12 14:54) [98]

> и не позволят обрабатывать файлы в несколько гигабайт

Зачем? Вот где в реальной жизни есть такие файлы под твою задачу?

← →
Джимми Камерманн (2013-03-12 15:08) [99]

> Ega23 © (12.03.13 14:54) [98]
> Зачем? Вот где в реальной жизни есть такие файлы под твою задачу?

Avatar"s BDRIP

← →
DevilDevil © (2013-03-12 15:10) [100]

> Ega23 © (12.03.13 14:54) [98]

когда программируешь универсальную библиотеку, надо программировать "с запасом"
сегодня у меня есть файлы 600мб, завтра появятся 1Гб, послезавтра 5Гб

вчера на char был Ansi-символом, сегодня уже Unicode

вчера на Delphi мы видели только Windows 32, сейчас оцениваем код с точки зрения совместимости с x64, iOS, MacOS и т.д.

Если в твоей работе нет необходимости в высокопроизводительных приложениях, то что ты хочешь доказать мне ?

← →
Rouse_ © (2013-03-12 15:14) [101]

> DevilDevil © (12.03.13 15:10) [100]
>
> Если в твоей работе нет необходимости в высокопроизводительных
> приложениях, то что ты хочешь доказать мне ?

Мимо :) Легыч как раз этим и занимается :)

← →
DevilDevil © (2013-03-12 15:16) [102]

> Rouse_ © (12.03.13 15:14) [101]
> Мимо :) Легыч как раз этим и занимается :)

Тогда АБСОЛЮТНО не понятно что он тут пытается доказать :)

← →
Игорь Шевченко © (2013-03-12 15:17) [103]

DevilDevil © (12.03.13 14:45) [97]

> 1) мой подход не уступает, а судя по бенчмарку опережает
> на 15%
> 2) они имеют ограничения на размер и не позволят обрабатывать
> файлы в несколько гигабайт
> 3) мне нужен был универсальный подход потоковой обработки
> данных, не завязываясь лишь на файлы в ОС Windows

Это все несущественно. Мне потребовалось решить задачу суммирования числе в файле, я ее решил а) быстро б) минимумом кода, без привлечения дополнительных библиотек, как твоей, так и других, коих в интернете тысячи.
Необходима другая задача, которая показывает, что именно твоя библиотека значительно ускоряет/облегчает труд написания кода для решения задач, и.т.п

← →
Rouse_ © (2013-03-12 15:19) [104]

Ну а как-же в плане повыпендриваться? :)))
На самом деле я показывал ему твой вариант оптимизации слияния блоков, который ты реализовал (сейчас с тобой кстати Жека соревнуется, пытается еще быстрее написать) и он в курсе твоих способностей. Но в чем-то он и прав, такие задачи крайне редки в настоящее время, нам просто "повезло" что пришлось влезть в такие дебри...
А по существу в 90 процентов случаев это избыточно (хотя я не говорю что вообще стоит бросать этот подход).

← →
Marser © (2013-03-12 15:21) [105]

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

← →
DevilDevil © (2013-03-12 15:23) [106]

> Игорь Шевченко © (12.03.13 15:17) [103]

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

Но мне это дело надоело, и я решил написать одну библиотечку, ориентированную на потоковую запись и чтение данных. Заодно создал специальные "классы" для файлов. Потому что это дело ресурсозатратное и уж лучше подобрать действительно оптимальный набор опций. Поэтому я сначала создал ветку по размеру буфера, потом - для для набора файловых опций. И действительно, как показали тесты, от выбранного буфера и опций, производительность может различаться в разы. Я предположил, что с потоковой обработкой данных могут сталкиваться и другие программисты - поэтому выложил библиотеку в сеть.

← →
DevilDevil © (2013-03-12 15:24) [107]

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

← →
DevilDevil © (2013-03-12 15:26) [108]

Удалено модератором
Примечание: дубль

← →
DevilDevil © (2013-03-12 15:27) [109]

> Rouse_ © (12.03.13 15:19) [104]

> А по существу в 90 процентов случаев это избыточно (хотя
> я не говорю что вообще стоит бросать этот подход).

конечно всё зависит от задач. Просто по работе и на фрилансе меня часто дёргают по таким поводам - данных много. Да я и рад - потому что оптимизация это моё я. :)

> (сейчас с тобой кстати Жека соревнуется, пытается еще быстрее написать)

посоветуй ему обновить файл CachedBuffers ))))
и там интерфейс сменился в Write и Read

← →
Джимми Камерманн (2013-03-12 15:30) [110]

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

← →
Rouse_ © (2013-03-12 15:34) [111]

> посоветуй ему обновить файл CachedBuffers ))))

он вообще на С++ пишет, говорит мол там есть много чего вкусного и готового в плане оптимизации.

← →
DevilDevil © (2013-03-12 15:36) [112]

> Rouse_ © (12.03.13 15:34) [111]
> он вообще на С++ пишет, говорит мол там есть много чего
> вкусного и готового в плане оптимизации.

да, современные С++ оптимизаторы прекрасны
но они не идут в сравнение с моим ассемблером ;))))))

хотя идут конечно. но всёравно у меня быстрее

← →
Rouse_ © (2013-03-12 15:36) [113]

ЗЫ: я вот про эту задачку говорил: http://dl.dropbox.com/u/70911765/FTS1Splitter.rar

а не про скорость чтения записи (аналог твоего CachedBuffers), они нам не принципиальны, не тут у нас узкое место...

← →
знайка (2013-03-12 15:40) [114]

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

← →
DevilDevil © (2013-03-12 15:41) [115]

> Rouse_ © (12.03.13 15:36) [113]

офтопим:
я тоже про неё. Твой Жека может взять хеши, пулы, списки - из коробки. У меня они на ассемблере, тщательно обдуманы
а файлы недооценивать не надо. их чтение/запись - действительно времязатратные процедуры. Хотя под Win7, да с быстрыми винчестерами конечно попроще

← →
brother © (2013-03-12 15:44) [116]

функция копирования большого файла при помощи этой байды будет быстрее стандартных примеров?

← →
Rouse_ © (2013-03-12 15:46) [117]

Ну посмотрим, если он сможет сделать объединение меньше твоих 7 секунд, в отличие от моего наколеночного варианта дающего скорость в районе 30 сек, значит будет о чем думать. Как я тебе и говорил меня устраивает скорость менее 5 секунд, все остальное слишком долго...

← →
Павиа (2013-03-12 15:50) [118]

Розыч. Опиши задачу совестно. Хочу попробовать в оптимизации одну штуку.

← →
Sapersky (2013-03-12 15:50) [119]

> Игорь Шевченко © (12.03.13 15:17) [103]
> я ее решил а) быстро б) минимумом кода, без привлечения
> дополнительных библиотек, как твоей, так и других, коих
> в интернете тысячи.

TFileMapper - это точно стандартный класс? Даже в XE3 не могу найти.

> Rouse_ © (12.03.13 15:46) [117]
офтоп:
а зачем тебе кстати столько ?
вроде как объединение баз у вас не часто должно происходить
такой скорости наверное можно достичь если сжать все файлы в zip
и кстати если не сортировать в алфавитном порядке - тоже можно сэкономить время (ибо для хеш-поисков вообще не важен алфавитной порядок)

← →
Павиа (2013-03-12 15:52) [121]

Розыч. Опиши задачу словесно. Хочу попробовать одну штуку из области оптимизации.

> brother © (12.03.13 15:44) [116]
> функция копирования большого файла при помощи этой байды
> будет быстрее стандартных примеров?

по тестам, которые я видел - ничего быстрее CopyFile и CopyFileEx не существует. Ибо там какие-то внутренние оптимизации используются

а если говорить о собственных поделиях... то хз. Медленнее работать не должно. Может быть для случаев копирования в рамках одного жёсткого диска нужно будет указать аргумент DoubleThreading false

Sapersky (12.03.13 15:50) [119]

Нет, обертка вокруг стандартных вызовов API. Ее текст в какой-то ветке выложен. Если принципиально, могу на API написать то же самое, +10 строк кода :)

> Павиа (12.03.13 15:50) [118]
> Розыч. Опиши задачу совестно. Хочу попробовать в оптимизации
> одну штуку.

Сейчас не могу, я дома болею. В принципе все данные по задаче я Диме по асе пересылал, если он сможет их найти в хистори то думаю выложит.
Суть такая есть куски дампа наших баз в определенном формате, нужно их слить в один единственный файл убрав дубляж. Формат файлов есть у DevilDevil.
Мой вариант (который в примере) делает это все за 30 сек примерно, Дима реализовал слияние в районе 7 сек. Jack128 в качестве спортивного интереса сейчас пилит код в свободное время пытаясь выйти на необходимые для нас 4 секунды.
Данная задача решалась примерно два года назад и мы ее решили в Ega23, а этот вот пример остался просто как для разминки пальцев и мозга :)

> Формат файлов есть у DevilDevil.
офтоп:
я так и не понял то описание, и хистори не осталось - комп сменили
я смотрел твои сорсы чтобы понять суть

> Если в твоей работе нет необходимости в высокопроизводительных
> приложениях, то что ты хочешь доказать мне ?

В высокопроизводительных - как раз есть. Мне не совсем понятна фишка зачитки таких гигантских кусков данных.
Да, у нас самый большой файл обновления весит 3,5 гига. Но это файл с определённой структурой, из которой "выдираются" нужные куски по-факту. А сами куски - не такие уж и огромные.
Как раз задница в обратном была: есть куча мелких файлов, но объединить это надо без дублирования (а дублирование там приличное, процентов 70). И когда 2 года назад экспериментировали, то на десятке больших файлов были вполне приемлемые результаты. Но когда выяснилось, что вместо десятка больших будет три сотни мелких - от тогда-то и приплыли.

> Ega23 © (12.03.13 16:06) [126]
офтоп:
задачи у вас простые. всё сводится:
1) чтение/запись файлов
2) хеш-поиск
3) грамотный менеджмент памяти

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

> Розыч. Опиши задачу словесно. Хочу попробовать одну штуку
> из области оптимизации.

Задача такова:
Есть информационная система, нечто похожее на Консультант. Т.е. множество различных документов (законы, стандарты, и т.д.).
Есть ежемесячные "обновления" данной системы (новые документы, поправки к старым). В данный момент полный комплект - около 300 обновлений с парой десятков тысяч документов.
В системе должен быть реализован быстрый поиск.
Соответственно, в каждом обновлении есть стрим со "словарём" для быстрого поиска. Формат словаря: сортированный список токенов, к каждому токену присобачен сортированный список ID документов, в которых данный токен встречается. Также дополнительным стримом лежит словарь токенов в LowerCase, к каждому токену присобачен список офсетов на case-sensetive токены.
Задача: из этих трёхсот стримов сформировать один, исключив дублирование токенов (дублирование, это когда токен "1" с вероятностью 99.99% встречается в каждом документе. А "ГОСТ13-43-4444" - скорее всего в нескольких).
Вроде так, если что - Розыч поправит. цифры тоже он помнит, сколько примерно эти стримы занимают, мне навскидку только процент повторяемости токенов в обновлениях (~70) помню.

> 2) хеш-поиск

Зачем? Там дихотомия, все словари отсортированы на этапе формирования обновления.

> мне навскидку только процент повторяемости токенов в обновлениях (~70) помню.
офтоп:
кстати вы там ошибку допустили при подсчёте повторений. на тех данных которые у меня были - дублирование составило около 50%

> Ega23 © (12.03.13 16:25) [129]
> Зачем? Там дихотомия, все словари отсортированы на этапе
> формирования обновления.

мне конечно хочется вставить скриншот "facepalm"
но из уважения к розычу - отвечу
затем, что так быстрее минимум на порядок

дихотомия подойдёт для списка документов.
могу кстати поделиться быстрой поисковой функцией по дихотомии по инту, на ассемблере

> DevilDevil © (12.03.13 16:26) [130]
> > мне навскидку только процент повторяемости токенов в
> обновлениях (~70) помню.
> офтоп:
> кстати вы там ошибку допустили при подсчёте повторений.
> на тех данных которые у меня были - дублирование составило
> около 50%

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

> Ega23 © (12.03.13 16:25) [129]
>
> > 2) хеш-поиск
>
> Зачем? Там дихотомия, все словари отсортированы на этапе
> формирования обновления.

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

> затем, что так быстрее минимум на порядок

Гм... С этого места по-подробнее, пожалуйста.

> Хэши самые быстрые, но мы по какой-то причине от них отказались

ЕМНИП, вопрос в хэш-функции был. Ну и на 2 мульёна токенов это при самом хреновом раскладе - 21 операция сравнения.

> Ega23 © (12.03.13 16:47) [135]

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

> Ega23 © (12.03.13 16:45) [134]
>
> > затем, что так быстрее минимум на порядок
> Гм... С этого места по-подробнее, пожалуйста.

на 2 миллиона элементов дихотомия даёт 11 сравнений
в хеше всего парочка

но в вашем случае:
1) вы сравниваете между собой строки, а не числа, да ещё и вызывая дополнительную функцию - просадка по производительности
2) дихотомия постоянно обращается к разной памяти, что крайне плохо отражается на производительности за счёт кеш-мисс
3) вы используете String, а не PAnsiChar - просадка по выделению/удалению/копированию памяти, преобразования к Wide для Unicode-версий Delphi + оверхед по расходу памяти (пустоты в куче, длинна, счётчик ссылок, ...)

> DevilDevil © (12.03.13 16:58) [137]
> 1) вы сравниваете между собой строки, а не числа, да ещё
> и вызывая дополнительную функцию - просадка по производительности
> 2) дихотомия постоянно обращается к разной памяти, что крайне
> плохо отражается на производительности за счёт кеш-мисс
> 3) вы используете String, а не PAnsiChar - просадка по выделению/удалению/копированию
> памяти, преобразования к Wide для Unicode-версий Delphi
> + оверхед по расходу памяти (пустоты в куче, длинна, счётчик
> ссылок, ...)

Во - первый грамотный анализ.
Ты собственно выделил три из пяти основных позиций с которыми мы и боролись.

> Rouse_ © (12.03.13 17:09) [138]
офтоп:
четвёртый - это наверное "сложение" id-шников документов
а пятый - работа с файлами

четвертый - оверхед токенов (перестраивали набор данных)
пятый - кэширование + быстрая работа с файловым кэшем

> на 2 миллиона элементов дихотомия даёт 11 сравнений

2^11=2048
Низачот

> вы сравниваете между собой строки, а не числа,

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

> вы используете String, а не PAnsiChar

Не используем мы стринг, всё на ansistring сделано.

> четвёртый - это наверное "сложение" id-шников документов

Да. вот тут засада знатная. Grow в листе на четверть каждый раз увеличивает, я даже как-то раз на нехватку памяти нарвался при сложении.

> а пятый - работа с файлами

Собственно, профайлер именно это и показал. Более 90% затрат - файловые операции.

> Собственно, профайлер именно это и показал. Более 90% затрат
> - файловые операции.

Окстись - 97 процентов на файловых операциях, не хочешь? :)
Все остальное летает. Серверную часть будем делать (которая для онлайна) - 64 бита only, 16 гигов склероза, все в память и даже парится не придется.

ЗЫ: ЛЕгыч ты уже вообще всю концепцию чтоль забыл?

> > вы сравниваете между собой строки, а не числа,
>
> Ну это да, тут ничего не поделаешь. Но на самом деле это
> не настолько критично, проблемы только в нестрогом соответствии
> на коротких токенах.
>
>
> > вы используете String, а не PAnsiChar
>
> Не используем мы стринг, всё на ansistring сделано.

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

> Окстись - 97 процентов на файловых операциях, не хочешь? :)

А 97% это меньше 90, да?
Я не помню точное число. Вроде бы из 14.5 секунд 13.7 - на FastGetItemData было. Оно, правда, не точное, под профайлером время довольно субъективно. Но вот процентное отношение - довольно точное.

> Ega23 © (12.03.13 17:25) [141]
> Rouse_ © (12.03.13 17:36) [144]

я предлагаю заканчивать флуд
лучше подумайте, кто мне будет помогать создавать быстрейший в мире парсер по XSD :)

> Строки уже не сравниваются - написан свой аналог на базе
> RAW данных.

Сравниваются. Я спецом глянул. Но это на самом поиске, GetToken

> DevilDevil © (12.03.13 17:40) [146]
> > Ega23 © (12.03.13 17:25) [141]
> > Rouse_ © (12.03.13 17:36) [144]
>
> я предлагаю заканчивать флуд
> лучше подумайте, кто мне будет помогать создавать быстрейший
> в мире парсер по XSD :)

Это с XML-ем? Если прислушаешься к озвученной мной и Олегом концепции вчерашней, по поводу совместимости с IXMLNode etc, то некоторое время (но оч маленькое два-три выходных максимум в месяц по шесть часов) мог бы выделить.

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

← →
Джимми Камерманн (2013-03-12 18:54) [154]

Удалено модератором
Примечание: Внимание! В Форуме не принято обсуждение настоящих правил и политики модеpиpования.

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

← →
Джимми Камерманн (2013-03-12 18:59) [156]

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

апдейты на сегодняшний день:

- немного изменил библиотеку и подходы
- отладил работу под x64 (в Delphi). Правда нужно немеряно памяти для стандартного чтения через TStringList в reading_benchmark

Благодаря пользователю Строчкин было найдено одно место, которое существенно тормозило запись файлов
Сейчас:
- баг исправлен
- в writing_benchmark добавлен вариант записи стандартным TextFile с буфером
- методы TCachedBufferWriter.Write() и TCachedBufferReader.Read() частично оптимизированы ассемблером под x86 и x64
- проведено тестирование на запись и чтение данных, разный размер и условия работы. Версия стабильна

скриншоты (Windows7, Delphi6):
http://a.fsdn.com/con/app/proj/cachedbuffers/screenshots/screen_reading.png
http://a.fsdn.com/con/app/proj/cachedbuffers/screenshots/screen_writing.png

таки запись в 464 раза быстрее, чем стандартным TFileStream :)

Ну прям уж в 464. Это ни в коей мере не показывает и не доказывает какой либо ущербности tfilestream. Никому в здравом уме не придет в голову использовать tfilestream в чистом виде так как используется он в тесте. На пару с буферизованным декоратором он отстает совсем не намного уже.

> DVM © (16.04.13 19:06) [160]

таки не соглашусь с тобой
знание сила, а незнание - слабость

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

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

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

а между тем методы Write и Read в CachedBuffers такие же как в TStream

>знание сила, а незнание - слабость

"Знание, что сила - это знание, является слабостью" (С) Jeer

Write и Read может и такие же, но у всей конструкции есть один концептуальный на мой взгляд недостаток - она не наследник tstream, что делает невозможным использование этого кода ВМЕСТО tstream там где принимается параметром tstream. Все же нужен адаптер для tstream.

> DVM © (16.04.13 22:23) [163]

ну...
там где действительно нужна скорость чтения/записи, логично пользоваться буфером напрямую. Логично переписать использование TStream на CachedBuffer

ну а если просто нужна совместимость со стандартным TStream - то достаточно просто написать враппер

← →
имя (2013-04-17 04:47) [165]

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

> DVM © (16.04.13 22:23) [163]

раз уж пошла такая пьянка
предлагаю обсудить "интерфейсную" часть врапперов TStream <--> CachedBuffer
т.е. как для пользователя будет выглядеть это преобразование

на повестке дня
1) TStream <-- TCachedBufferReader
2) TStream <-- TCachedBufferWriter
3) TCachedBufferReader <-- TStream
4) TCachedBufferWriter <-- TStream

по поводу 3 и 4
по аналогии с TCachedFileReader/TCachedFileWriter (а скоро наверное появится TCachedMemoryReader/TCachedMemoryWriter)
логично сделать TCachedStreamReader и TCachedStreamWriter

а вот с 1 и 2 - не знаю
мне кажется типы TStreamReader и TStreamWriter - не читабельно

по идее можно сделать так:
function CreateStreamAsCachedBuffer(var Reader: TCachedBufferReader): TStream; overload; function CreateStreamAsCachedBuffer(var Writer: TCachedBufferReader): TStream; overload;

может быть сделать классы
TStreamAsCachedReader/TStreamAsCachedWriter, которые в конструкторе принимают либо ридер, либо райтер ?

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