Скорость записи файла (исследование)

[waleri]

Сообщение от kta87

Интересуют все же ответы или рассуждения на моменты которые я раскрыл в первом посте.

А что тут рассуждать, я же вам указал источник...

[kta87]

Сообщение от pproger

медицина бессильна.

Так не болейте. Вы вообще графики читать умеете? У меня что зависимости скорости от расширений. Я же ясно выразился что исследовалась длинна побайтовой записи. Какая запись в блочное устройство, если я пишу что файл открывается THandle а не HDD.
Давайте прекратим рассказывать кто в земле красит редиску...
Когда посты читаешь читать нужно то, что написано а не то что хочется увидеть, а если не понятно что то, то как правило уточняют прежде чем писать.
Мда, я Вам от души желаю не болеть.
п.с. Репутацию Вы понизили?

[Человек_Борща]

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

угу, проблема в том, что кэш - это ОЗУ а не ПЗУ. И получается твои данные с 50% примесью мусора.
Реальная скорость чтения/записи с камня вообще читается не из файловых операций, а напрямую из ЖД, т.е. S.M.A.R.T. данные.

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

Поддерживаю.

[ROD]

Интересует описание методики измерения, а так же сами "инструменты".

[kta87]

Сообщение от Человек_Борща

Поддерживаю.

Да я сам код писал и записи и измерения времени.
ROD, я делаю так

var
  iCounterPerSec: TLargeInteger;
  C1, C2: TLargeInteger;
...
Begin
  QueryPerformanceFrequency(iCounterPerSec);
   QueryPerformanceCounter(C1);
...
Тут код, продолжительность выполнения которого измеряю;
...
QueryPerformanceCounter(C2);
ATime:= FormatFloat('0.0000000000000', (C2 - C1) / iCounterPerSec);
end;

[ROD]

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

Теперь отступим от метрологии, и подумаем о самой записи. Большая часть носителей - жесткие магнитные диски. К последовательно расположеным данным скорость доступа (чтение и запись) может быть достаточно высока (на моем винте с 7200 оборотов производителем заявлена пиковая скорость до 160 Мбит\сек). Проблема в том, что из-за высокой фрагментации может оказаться невозможным запись в подряд идущие кластеры, а это означает резкое увеличение времени отклика винчестера. Плюс тут накладываются задержки, связанные с реализацией самого драйвера (если мы пишем не на голый винт, а на винт с файловой системой). Плюс такой момент, что на винте адресация идет по кластерно. Драйвер ФС в лююбом случае пишет/читает кластер целиком. (вроде бы стандартный размер кластера, который предлагает винда для NTFS, 4 кб.) Соответственно 2 байта или 1 килобайт или 4 килобайта вы будете писать одинаковое кол-во времени.

Кроме того, есть такая неприятная (в вашем случае) функция ОС - разделение ресурсов компьютера между программами. Это значит, что другие программы снижают скорость работы вашей с винчестером. Даже если они не трогают винчестер, как вы думаете, где хранится файл подкачки (своп) ? Правильно, на винчестере. И это тот случай, когда сама система "отнимает у вас время".

В принципе, если вам ресурсы позволяют, вы можете взять пустой винт, подключить его к компу и (если вы делаете сие под виндой) через API функции напрямую писать данные на нулевый винт. В этом случае эксперимент будет более-менее "чистым", с поправкой на задержки в самом API.

[kta87]

Сообщение от ROD

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

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

[ROD]

Сообщение от kta87

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

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

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

[waleri]

Кстати, сделайте еще один експеримент - записывайте сначала скажем 4 байта а потом уже блоки с "данными".

[kta87]

Сообщение от ROD

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

Если смотреть все же глазами то в 1 посте есть:

Хочу поделиться на мой взгляд интересными результатами исследования на примере одного файла
...
Размер файла: 13376719 байт;

По оси Х не длинна записываемого файла, а длинна записи в файл.
Файл открывается 1 раз, затем записывается на разную длину.
Видимо все непонимания в этом топике именно из-за этого!

Сообщение от ROD

хотя бы несколько тысяч раз.

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