Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2013.06.02;
Скачать: CL | DM;

Вниз

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

 
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_ стал для меня
> таким человеком

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


 
DevilDevil ©   (2013-01-27 01:06) [69]

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

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


 
DevilDevil ©   (2013-01-27 01:11) [70]

> 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]

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


 
картман ©   (2013-01-27 01:32) [74]


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

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


 
DevilDevil ©   (2013-01-27 01:59) [75]

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


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

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

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

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


 
картман ©   (2013-01-27 11:53) [76]


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


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

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


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


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

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


 
Pavia ©   (2013-01-27 12:47) [78]


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

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


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

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


 
Kerk ©   (2013-01-27 13:10) [79]

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


 
DevilDevil ©   (2013-01-27 14:51) [80]

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

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

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


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

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


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



Страницы: 1 2 3 вся ветка

Текущий архив: 2013.06.02;
Скачать: CL | DM;

Наверх




Память: 0.66 MB
Время: 0.012 c
15-1358278949
masha
2013-01-15 23:42
2013.06.02
беговые лыжи


15-1359232203
Юрий
2013-01-27 00:30
2013.06.02
С днем рождения ! 27 января 2013 воскресенье


15-1358864685
Nucer
2013-01-22 18:24
2013.06.02
Исключение при доступе к памяти


15-1359029346
Студент
2013-01-24 16:09
2013.06.02
Колонка и микрофон.


2-1351936642
Очень Злой
2012-11-03 13:57
2013.06.02
Получить текст под мышкой из чужого окна