Оптимальный размер буфера для чтения/записи файла

← →
Rouse_ © (2013-01-25 20:12) [40]

> Pavia © (25.01.13 20:10) [39]

Ну у меня это ничем не подтвердилось.

← →
DVM © (2013-01-25 20:37) [41]

> DevilDevil © (25.01.13 12:38)

>
> Периодически сталкиваюсь с задачами потокового чтения/записи
> файлов. Выбираю разные подходы и размеры буферов. И в последнее
> время всё чаще возникала мысль написать что-то более-менее
> универсальное.
>

Советую оформить буферизованный ввод-вывод в виде класса-наследника TStream (по-умному декоратора, обертки), тогда можно будет сделать буферизованный ввод-вывод для любого другого класса-потока, в. том числе и TFileStream. Размер буфера можно сделать свойством или передавать в конструктор. Максимальный размер буфера я бы выбрал 64к, минимальный 4к.

← →
QAZ10 (2013-01-25 20:52) [42]

> тебе говорит что нибудь такое понятие как "кэшмисс" ?

ну ты загоняешся бро, непотеме ;)
при чем тут кэш чтения файла и кэшь проца да еще и с компилятором дельфи

← →
brother © (2013-01-26 04:00) [43]

Розыч, прокомментируй [14] об этом размышления были?

← →
DevilDevil © (2013-01-26 09:29) [44]

> DVM © (25.01.13 20:37) [41]

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

к тому же логика работы буферезированого записывателя отличается от логики буферизированого читателя. а у TStream есть оба метода + определённый обвес типа Seek, Position, Size, всё в типах int64

вот например как можно будет записать TRect:
var R: TRect; begin ... if (DataWriter.Margin >= sizeof(TRect)) then begin // обычная запись в буфер данных PRect(DataWriter.Current)^ := R; inc(integer(DataWriter.Current), sizeof(TRect)); dec(DataWriter.Margin, sizeof(TRect)); end else begin // умная функция с распределённой записью DataWriter.Write(@R, sizeof(TRect)); end; end;

← →
DVM © (2013-01-26 10:16) [45]

> DevilDevil © (26.01.13 09:29) [44]

> я решил воспользоваться более тонкими материями, более низким
> уровнем
> ибо вызов Read/Write на каждый чих может негативно сказаться
> на производительности

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

> к тому же логика работы буферезированого записывателя отличается
> от логики буферизированого читателя. а у TStream есть оба
> метода + определённый обвес типа Seek, Position, Size, всё
> в типах int64

Без проблем можно реализовать обе логики в одном или двух классах, перекрыв соответствующие методы. На практике TStream оказывается много удобнее, чем что-то свое, т.к. поддерживается всеми и VCL и сторонним кодом.

← →
DVM © (2013-01-26 10:19) [46]

> DevilDevil © (26.01.13 09:29) [44]

> ибо вызов Read/Write на каждый чих может негативно сказаться
> на производительности

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

← →
DVM © (2013-01-26 10:34) [47]

> вот например как можно будет записать TRect:

На мой взгляд, запись всех необходимых типов удобнее оформить в виде class helper для TStream, тогда все стримы, в том числе и наш буферизованный получают возможность писать/читать нужные нам типы данных.

Если же у нас совсем древняя версия Delphi и class helper-ы не поддерживаются, тогда имеет смысл опять таки воспользоваться паттерном декоратор и в класс такого декоратора добавить все нужные нам методы. Опять таки все стримы получают возможность писать/читать наши типы данных.
Лучше чуть-чуть пожертвовать скоростью, зато потом получить чистый и наглядный код, удобный в поддержке и очень гибкий в использовании. Это к теме универсальности.

← →
DevilDevil © (2013-01-26 11:09) [48]

> DVM © (26.01.13 10:16) [45]

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

в целом - не вопрос, можно что-нибудь потестировать, мне интересно!
но давай денька через 4
потому что как раз сейчас я занят другим тестовым приложением, где надо выжать максимум скорости :)

← →
Rouse_ © (2013-01-26 13:20) [49]

> brother © (26.01.13 04:00) [43]
> Розыч, прокомментируй [14] об этом размышления были?

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

← →
DVM © (2013-01-26 13:42) [50]

> DevilDevil © (26.01.13 11:09) [48]

> ты рассуждаешь как типичный программист

ясное дело, я и есть программист, по крайней мере мне так кажется :)

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

Вряд ли слабым местом при работе именно с файлами окажется TStream, но дело твое конечно.

> но давай денька через 4

давай

← →
DevilDevil © (2013-01-26 14:00) [51]

> DVM © (26.01.13 13:42) [50]

придумай пока пожалуйста достойную задачу
варианты кстати сюда можно выкладывать )

← →
Аббат Пиккола (2013-01-26 14:23) [52]

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

← →
DevilDevil © (2013-01-26 14:39) [53]

> Аббат Пиккола (26.01.13 14:23) [52]

потому что у меня нет такого огромного количества разнообразного оборудования, чтобы после тестов на котором придти к однозначному мнению по вопросу

← →
brother © (2013-01-26 16:07) [54]

> размер буфера кратен размеру файлового кластера

я о том же, только вот вроде как предела нет)

← →
Rouse_ © (2013-01-26 17:29) [55]

> brother © (26.01.13 16:07) [54]
> я о том же, только вот вроде как предела нет)

Не понял, предела чему?

← →
QAZ10 (2013-01-26 18:11) [56]

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

← →
brother © (2013-01-26 18:47) [57]

> Не понял, предела чему?

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

а о конкретном рекомендуемом размере разговора нет, значит он может быть бооооольшой) (да шутю я)

← →
DVM © (2013-01-26 19:13) [58]

Удалено модератором
Примечание: не цитируем...

← →
Rouse_ © (2013-01-26 20:38) [59]

> QAZ10 (26.01.13 18:11) [56]
> это минимальная единица чтения\записи должна быть размером
> в кластер, а не буфер

Слово "кратность", стало быть ты пропустил?

> ну ты загоняешся бро, непотеме ;)

Так, устаю я от тебя. Прими к сведению, лурковский и молодежный сленг у нас не приветствуются.

> а о конкретном рекомендуемом размере разговора нет, значит
> он может быть бооооольшой)

По поводу кратности? Ну в принципе да. Вон Pavia тоже утверждает и мне нет смысла ему не верить, но просто у меня не прошли тесты на озвученных им объемах, поэтому я займу нейтральную позицию.

← →
Аббат Пиккола (2013-01-26 21:18) [60]

DevilDevil © (26.01.13 14:39) [53]
> Аббат Пиккола (26.01.13 14:23) [52]

потому что у меня нет такого огромного количества разнообразного оборудования, чтобы после тестов на котором придти к однозначному мнению по вопросу

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

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

← →
Аббат Пиккола (2013-01-26 21:20) [61]

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

← →
DevilDevil © (2013-01-26 21:26) [62]

> Аббат Пиккола

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

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

← →
Pavia © (2013-01-26 22:26) [63]

> Хотя, сдается мне, ради каких-то 10% выигрыша все это не
> имеет ровно никакого смысла.

Дело в том что выигрыш и проигрыш при чтении может доходить до 2 раз (±6 db).

И одно дело перекодировать файл 15-30 минут, а другое 3 минуты. (Правда это ещё нестрашно, а вот соседи ещё 2 часа на CD пишут)

> можно просто потребовать.

Не знаю как у Вас, а у нас и наших клиентов экономика плановая. И пока старое не сломается не заменят. Либо морально не устареет, а это 10 лет.

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

← →
Аббат Пиккола (2013-01-26 23:18) [64]

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

← →
DevilDevil © (2013-01-27 00:06) [65]

> Аббат Пиккола (26.01.13 23:18)

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

ты не тестируешь все возможные размеры буферов от 1 до 3мб с шагом в 1 байт. Всё потому, что какие то дядьки в своё время аргументировали размеры 4кб и 64кб. авторитетные дядьки

← →
Аббат Пиккола (2013-01-27 00:53) [66]

2 DevilDevil © (27.01.13 00:06) [65]

Возможно, Вас удивит, но я вовсе не считаю, что размер буфера должен быть кратен размеру страницы. Все об этом твердят, но когда мне понадобилось практически подобрать размер буфера, я ничего такого не обнаружил. Буфер, размером 30 кбайт работал ТОЧНО ТАК ЖЕ, как и буфер, размером 32. При этом НАМНОГО БЫСТРЕЕ, чем буфер размером 16. А дальше (свыше 30 кбайт) скорость ПРАКТИЧЕСКИ НЕ ИЗМЕНЯЛАСЬ. Задача была простой - менять четный и нечетный байт местами в огромных файлах.

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

За то время, которое Вы обсуждаете сабж, я бу уже написал и отладил модуль автонастройки размера буфера.
Как бы я рассуждал?
Сокрость либо не критична вообще либо я собираюсь обрабатывать много файлов. Следовательно, я собираюсь обрабатывать много файлов. А если так. то я могу себе позволить часть файлов обработать неоптимально, чтобы потом обрабатывать остальные оптимально. следовательно, я могу набирать статистику, поигрывая размером буфера. И анализировать результаты. Прямо в процессе использования программы. Сначала грубо, затем все тоньше и тоньше настраивая (это будет требовать все большую выборку) нужный размер под "оптимальный". Если окажется, что он равен сдуру 37.8 кбайт, я не буду удивляться или спорить на эти темы на форумах. Я просто узнаю нечто для себя новое в мире стереотипов, в котором мы живем. Мне это нравится. Разумеется, если я потом об этом факте сообщу, найдется 100500 "авторитетных мнений", объясняющих мне, недостойному, почему это так. Но я не буду уязвлен, ибо скромность аббатам приличествует. :)

← →
Аббат Пиккола (2013-01-27 01:04) [67]

Разумеется, я не настаиваю на подобном решении, если лень или неохота. Но в качестве идеи ведь можно рассмотреть и такой вариант. Чисто абстрактно. Чем больше вариантов Вы рассмотрите, тем лучшее решение Вы в конечном итоге примите.
А на авторитет я полагаюсь ...
Знаете когда?
Вот когда у меня соврешенно нет времени самому разбираться, и слишком высоки риски ошибиться, а цена ошибки - жизнь. Например, если болит что-то в районе аппендикса. Я, разумеется, доверюсь врачу. Причем, взможно даже - первому попавшемуся.

← →
Rouse_ © (2013-01-27 01:05) [68]

> В плане размера буфера для чтения - Rouse_ стал для меня
> таким человеком

Дим, ты слишком категорично рассуждаешь, я же выше ответил, что Павиа (к мнению которого я прислушиваюсь периодически) сказал что вероятно на других размерах будут другие данные. Я не знаю какое железо им тестировалось (я на пользователях обкатывал ну если точнее на наших диллерских отделах :) но если человек говорит такое, то как минимум имеет смысл к этому прислушаться. Вполне вероятно что на серверных системах его мнение стоит больше чем мое...

> Аббат Пиккола (27.01.13 00:53) [66]

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

> Rouse_ © (27.01.13 01:05) [68]

1мб это слишком большой буфер
и грозит он повышенным количеством кэшмисс
а мне оно не нужно )
мне нужен оптимальный размер

офтоп:
кстати морально подготавливайся, скоро я тебя приятно удивлю скоростью. я уже вижу свет в конце тоннеля )

← →
Аббат Пиккола (2013-01-27 01:18) [71]

Всякая задача либо имеет единственное решение (a), либо имеет множество решений (b), либо вообще не имеет решения (c).

Давайте еще раз определимся с задачей.
1. Вы хотите "раз и навсегда" зафиксировать некотрую цифру в качестве оптимальной путем голосования участников Никейского Собора или решением авторитетнейшего из епископов?
2. Вы хотите дать ряд настроек юзеру, чтобы он выбрал и колеблетесь, какие цифры стоит включить в список?

← →
Аббат Пиккола (2013-01-27 01:19) [72]

на данный момент использую буферы 256кб и 64кб

И какой быстрее работает?

← →
Аббат Пиккола (2013-01-27 01:25) [73]

Вопрос снят - видно это чтение и запись.

> DevilDevil © (27.01.13 01:06) [69]
>
> > Аббат Пиккола (27.01.13 00:53) [66]
>
> я перфекционист, я хочу знать наверняка
> на данный момент использую буферы 256кб и 64кб
> если будут другие мнения авторитетных дядюшек - я прислушаюсь

а больше похож на идолопоклонника-политеиста

> Аббат Пиккола (27.01.13 01:18) [71]
> Всякая задача либо имеет единственное решение (a), либо
> имеет множество решений (b)

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

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

> картман © (27.01.13 01:32) [74]

я агностик. а на кого я там похож как вам кажется - лучше не выносить в тематическую ветку

> DevilDevil © (27.01.13 01:59) [75]

> > картман © (27.01.13 01:32) [74]
>
> я агностик. а на кого я там похож как вам кажется - лучше
> не выносить в тематическую ветку

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

← →
QAZ10 (2013-01-27 11:54) [77]

> Слово "кратность", стало быть ты пропустил?

есть такое, зато я уточнил важную деталь , а ты взял и затер пост :(

> 1мб это слишком большой буфери грозит он повышенным количеством
> кэшмисс

Про, кэшмисс я бы не заикался. Пробовал я тестировать на него. Система кэшев сложнее чем система работы с жёстким. В результате получил противоречивые данные. С одной стороны, результаты коррелируют с результатами других тестов с другой авторитетное мнение что это не кэш промахи, а ЦПУ слабый.

> на данный момент использую буферы 256кб и 64кб

Запись я не тестировал. Но побочным результатом тестом на чтение было то, что 64 КБайта для записи не является эффективным.

Не могу удержаться. Надеюсь, юмор не слишком тонок :)
http://ic.pics.livejournal.com/kit58/2089172/510456/510456_original.jpg

> картман © (27.01.13 11:53) [76]
> это была критика твоего подхода, извини, если грубо получилось,
> впредь постараюсь избегать подобного... Но если ты задашь
> вопрос "как составить идеальный план выполнения запроса
> - раз и навсегда", то я не смогу удержаться

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

> Pavia © (27.01.13 12:47) [78]
> С одной стороны, результаты коррелируют с результатами других
> тестов с другой авторитетное мнение что это не кэш промахи, а ЦПУ слабый.

распиши поподробнее пожалуйста

> Запись я не тестировал. Но побочным результатом тестом на
> чтение было то, что 64 КБайта для записи не является эффективным.

не совсем понял
ты имеешь ввиду, "64кб на чтение" ?
сравнивал ли ты 64/256/1024 ?

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