размер буфера
Всем привет!!!
Вот у нас есть программа к примеру....
#include <stdio.h>
#include <errno.h>
#define BUF_SIZE 256
int main (int argc, char *argv [])
{
FILE *in_file, *out_file;
char rec [BUF_SIZE];
size_t bytes_in, bytes_out;
if (argc != 3) {
printf ("Usage: cpC file1 file2\n");
return 1;
}
in_file = fopen (argv [1], "rb");
if (in_file == NULL) {
perror (argv [1]);
return 2;
}
out_file = fopen (argv [2], "wb");
if (out_file == NULL) {
perror (argv [2]);
return 3;
}
/* Process the input file a record at a time. */
while ((bytes_in = fread (rec, 1, BUF_SIZE, in_file)) > 0) {
bytes_out = fwrite (rec, 1, bytes_in, out_file);
if (bytes_out != bytes_in) {
perror ("Fatal write error.");
return 4;
}
}
fclose (in_file);
fclose (out_file);
return 0;
}
Объясните мне пож почему BUF_SIZE 256 а не скажем 4096, и от чего это зависит
Вот у нас есть программа к примеру....
#include <stdio.h>
#include <errno.h>
#define BUF_SIZE 256
int main (int argc, char *argv [])
{
FILE *in_file, *out_file;
char rec [BUF_SIZE];
size_t bytes_in, bytes_out;
if (argc != 3) {
printf ("Usage: cpC file1 file2\n");
return 1;
}
in_file = fopen (argv [1], "rb");
if (in_file == NULL) {
perror (argv [1]);
return 2;
}
out_file = fopen (argv [2], "wb");
if (out_file == NULL) {
perror (argv [2]);
return 3;
}
/* Process the input file a record at a time. */
while ((bytes_in = fread (rec, 1, BUF_SIZE, in_file)) > 0) {
bytes_out = fwrite (rec, 1, bytes_in, out_file);
if (bytes_out != bytes_in) {
perror ("Fatal write error.");
return 4;
}
}
fclose (in_file);
fclose (out_file);
return 0;
}
Объясните мне пож почему BUF_SIZE 256 а не скажем 4096, и от чего это зависит
хз.... может из-за размера класстера.... если мне память не изменяет он 512...
Можно указать любое число (по крайней мере по данному коду это вроде так), поэксперементируйте со значениями.
В прграммировании есть принцип - чем больше расходует программа памяти тем она "быстрее". Если файл "маленький", то его обычно вообще читают за раз, а потом работают с ним в памяти. По идее нужно искать оптимум расход памяти - быстродействие. Но я неустаю повторять - "Как говорит старина Кнут - "Преждевременная оптимизация - корень всех зол"". Так что прежде всего понятность кода. Незря же в прототипе этих функций после указателя на буфер идет размер читаемого элемента и число элементов.
Код:
size_t fread ( void * ptr, [COLOR="Red"]size_t size, size_t count[/COLOR], FILE * stream );
Об этом говорит не только Кнут, но и все профессиональные программисты. Ибо спецпроги найдут уязвимые места получше программиста. А вот что ты хотел сказать про размер элемента и их число, я не понял) Причем здесь понятность кода?
Ну простейший пример, если читешь некоторое число записей, то лучше вторым параметор указать размер записи (size), а третьим число записей (count), а не передавать вторым параметром единицу, а третьим произведение size*count.
А вообще это было для красного словца, не было другого примера в голове. Пиво там. Завтра в оптуск.
А вообще это было для красного словца, не было другого примера в голове. Пиво там. Завтра в оптуск.
Рассматривая конкретно этот пример размер буфера можно сделать кратным как размеру буфера стандартной библиотеки (хз, можно в доках поискать, но, наверно, кратно 256), так и размеру кластера файловой системы (думаю, во всех размер кластера кратен 256). В некоторых случаях (если ОС стара и убога или ты работаешь на низком уровне) это (кратность) может оптимизировать обращения к диску, но с современных ОС считываемые с диска данные буферизуются, кажется, не менее, чем дважды (дисковый кэш, и файловый буфер стандартной библиотеки), это не считая собственного кэша HDD. Так что эта кратность особо ни на что не повлияет. Верны ли эти предположения? Тогда 256 является оптимально?
Если обратиться к нативе апе то чтение и запись в файл осущ с помощью системных вызовов
NtWriteFile
NTSYSAPI
NTSTATUS
NTAPI
NtWriteFile(
IN HANDLE FileHandle,
IN HANDLE Event OPTIONAL,
IN PIO_APC_ROUTINE ApcRoutine OPTIONAL,
IN PVOID ApcContext OPTIONAL,
OUT PIO_STATUS_BLOCK IoStatusBlock,
IN PVOID Buffer,
IN ULONG Length,
IN PLARGE_INTEGER ByteOffset OPTIONAL,
IN PULONG Key OPTIONAL
);
и
NtReadFile
NTSYSAPI
NTSTATUS
NTAPI
NtReadFile(
IN HANDLE FileHandle,
IN HANDLE Event OPTIONAL,
IN PIO_APC_ROUTINE ApcRoutine OPTIONAL,
IN PVOID ApcContext OPTIONAL,
OUT PIO_STATUS_BLOCK IoStatusBlock,
OUT PVOID Buffer,
IN ULONG Length,
IN PLARGE_INTEGER ByteOffset OPTIONAL,
IN PULONG Key OPTIONAL
);
У обоих этих вызовов есть буфер и чем меньше мы делаем этот самый буфер тем больше вызовов получаем а на кождый вызов тратится время те на файл 4000 байт с буфером чтения/запись 256 байт будет истрачено 16 выззовов а с буфером 4096 один. Теперь я думаю где предел указания буфера и нужно ли его привязывать к кратности кластера в файловой системе. Верно ли это? И как посчитать системные вызовы NtReadFile/NtWriteFile этой программы?
Если обратиться к нативе апе то чтение и запись в файл осущ с помощью системных вызовов
NtWriteFile
NTSYSAPI
NTSTATUS
NTAPI
NtWriteFile(
IN HANDLE FileHandle,
IN HANDLE Event OPTIONAL,
IN PIO_APC_ROUTINE ApcRoutine OPTIONAL,
IN PVOID ApcContext OPTIONAL,
OUT PIO_STATUS_BLOCK IoStatusBlock,
IN PVOID Buffer,
IN ULONG Length,
IN PLARGE_INTEGER ByteOffset OPTIONAL,
IN PULONG Key OPTIONAL
);
и
NtReadFile
NTSYSAPI
NTSTATUS
NTAPI
NtReadFile(
IN HANDLE FileHandle,
IN HANDLE Event OPTIONAL,
IN PIO_APC_ROUTINE ApcRoutine OPTIONAL,
IN PVOID ApcContext OPTIONAL,
OUT PIO_STATUS_BLOCK IoStatusBlock,
OUT PVOID Buffer,
IN ULONG Length,
IN PLARGE_INTEGER ByteOffset OPTIONAL,
IN PULONG Key OPTIONAL
);
У обоих этих вызовов есть буфер и чем меньше мы делаем этот самый буфер тем больше вызовов получаем а на кождый вызов тратится время те на файл 4000 байт с буфером чтения/запись 256 байт будет истрачено 16 выззовов а с буфером 4096 один. Теперь я думаю где предел указания буфера и нужно ли его привязывать к кратности кластера в файловой системе. Верно ли это? И как посчитать системные вызовы NtReadFile/NtWriteFile этой программы?
Стандартный размер сектора диска всегда был 512 байт. А вот размер кластера - величина изменчивая, зависящая от файловой системы.
Размер кластера, если не ошибаюсь, можно узнать (есть соответствующие функции API).
Размер кластера, если не ошибаюсь, можно узнать (есть соответствующие функции API).
Цитата: cheburator
Стандартный размер сектора диска всегда был 512 байт. А вот размер кластера - величина изменчивая, зависящая от файловой системы.
Размер кластера, если не ошибаюсь, можно узнать (есть соответствующие функции API).
Размер кластера, если не ошибаюсь, можно узнать (есть соответствующие функции API).
Спосибо конечно за напоминание, это мне известно, но здесь никто про сектора дисков не говорил. Конечно можно сначало узнать размер кластера файловой системы, а потом такого размера делать буфер сложно вато конечно но можно. Но вопрос не в этом. Будет это оптимально создавать буфер кратный кластеру файловой системы? Или лучше создать больший буфер? А если больший то насколько?
[quote=like-nix]Рассматривая конкретно этот пример размер буфера можно сделать кратным как размеру буфера стандартной библиотеки (хз, можно в доках поискать, но, наверно, кратно 256), так и размеру кластера файловой системы (думаю, во всех размер кластера кратен 256).
...............
Спосибо конечно за напоминание, это мне известно, но здесь никто про сектора дисков не говорил. [/quote]
Правильно, про сектора никто не говорил - почему-то все говорят про "кластеры", которые с точки зрения программы к логике процесса чтения/записи диска не относятся. Ведь даже на чистом асме под ДОС обращение к диску происходит по секторам (int 13h и int 25h/26h)
А для IBM-PC совместимых машин размер кластера может быть только больше, чем 512. Учите матчасть.
А цифирь эта взята "с потолка". Правда, с учётом скорости диска, заполнение одного большого буфера выполняется быстрее, чем несколько раз - мелкого.
И стековые буфера вообще лучше не использовать - стек не безразмерный, чтоб его захламлять. Кроме того, работа программы быстрее от этого не станет - функци чтения всё равно, от какой области памяти адрес будет.
...............
Спосибо конечно за напоминание, это мне известно, но здесь никто про сектора дисков не говорил. [/quote]
Правильно, про сектора никто не говорил - почему-то все говорят про "кластеры", которые с точки зрения программы к логике процесса чтения/записи диска не относятся. Ведь даже на чистом асме под ДОС обращение к диску происходит по секторам (int 13h и int 25h/26h)
А для IBM-PC совместимых машин размер кластера может быть только больше, чем 512. Учите матчасть.
А цифирь эта взята "с потолка". Правда, с учётом скорости диска, заполнение одного большого буфера выполняется быстрее, чем несколько раз - мелкого.
И стековые буфера вообще лучше не использовать - стек не безразмерный, чтоб его захламлять. Кроме того, работа программы быстрее от этого не станет - функци чтения всё равно, от какой области памяти адрес будет.