Проект "CachedBuffers"

← →
Германн © (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]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну посмотрим, если он сможет сделать объединение меньше твоих 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
и кстати если не сортировать в алфавитном порядке - тоже можно сэкономить время (ибо для хеш-поисков вообще не важен алфавитной порядок)

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