[C] Чтение файла с помощью fgetc

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

Тем не менее, эти результаты явно не в пользу fgetc

А зачем файл читать посимвольно? Лучше же read'ом читать большими блоками, кратными размеру блока на диске.

> А зачем файл читать посимвольно? Лучше же read'ом читать большими блоками, кратными размеру блока на диске.

В этом и заключается моя позиция.

А что, кто-то рекомендует посимвольно? Покажите мне этих людей!

> кратными размеру блока на диске.

Самое забавное, что судя по моим таблицам эффективнее всего блоки, немного меньшие блока на диске. Это странновато, конечно.

А что, кто-то рекомендует посимвольно? Покажите мне этих людей!

В том самом треде, на который я дал ссылку в посте, есть два примера: yoghurt, Eshkin_kot .

Странновато.

Ну, например, при обработке CGI запросов (multipart/form-data) приходится искать ограничитель. И тут уж приходится придумывать, как скорость увеличить. Некоторые считывают входной поток посимвольно, параллельно со считыванием проверяя наличие разделителя. Мне проще скинуть все на жесткий диск (или даже сделать mmap), а потом читать построчно и вызывать strstr. Вот надо будет по скорости прикинуть, насколько этот способ медленнее посимвольного считывания.

Болезный, где ты в том треде увидел явный вызов fgetc?

while ((ch = (receive_getc)()) != EOF)

receive_getc тут может указывать хоть на чёрта лысого.

Да и вообще в том топике речь шла о сети, не?

Я бы читал блоками в софтовый буфер, а из него брал посимвольно. Должно быть весьма шустро.

> Болезный, где ты в том треде увидел явный вызов fgetc?

Цитирую: «Функция receive_getc = fgetc(stdin)»

>stdin

> stdin

Ну и? Чем этот поток лучше потока из файла? Давай я сделаю cat file | тестилка , результат особо не поменяется.

Тем, что в своём примере ты юзаешь таки винт ещё, а на stdin данные могут поступать откуда угодно.

> Тем, что в своём примере ты юзаешь таки винт ещё, а на stdin данные могут поступать откуда угодно.

В предыдущем треде негласно считали, что это винт, ибо практически в каждом сообщении говорили про кэш винта.

Помимо кеша винта есть ещё сокбуфы, да и чего только нет.

> Помимо кеша винта есть ещё сокбуфы, да и чего только нет.

Я сейчас проверю cat /dev/zero | head -cX | тестилка . Мне уже стало интересно, как оно себя поведёт без винта.

> ибо практически в каждом сообщении говорили про кэш винта.

Я про кеш винта ничего не говорил :)

Помимо кеша винта есть ещё сокбуфы, да и чего только нет.

Вот, пожалуйста, без использования винта, только память:

Mandriva, stdin (/dev/zero | head)                          
метод | буфер | размер | время | мб/сек|
---------------------------------------|
fgetc |     - |    500 |    43 |  11.6 |
---------------------------------------|
fread |     1 |    500 |    90 |   5.5 |
      |     2 |    500 |    45 |  11.1 |
      |     4 |    500 |    26 |  19.2 |
      |     8 |    500 |    13 |  38.5 |
      |    16 |   1000 |    16 |  62.5 |
      |    32 |   1000 |    10 | 100.0 |
      |    64 |   2000 |    13 | 153.9 |
      |   128 |   2000 |    14 | 142.9 |
      |   256 |   2000 |    15 | 133.3 |
      |   512 |   2000 |    14 | 142.9 |
      |  1024 |   2000 |    15 | 133.3 |
      |  2048 |   2000 |    13 | 153.9 |
      |  4096 |   2000 |    13 | 153.9 |
      |  8192 |   2000 |    15 | 133.3 |
      | 16384 |   2000 |    14 | 142.9 |
---------------------------------------|

Памяти более 2 ГБ свободно не было, а в своп лезть очень не хотелось, потому максимальный размер входного потока 2 ГБ. Тем не менее, fgetc всё равно показал свою неэффективность.

А если там гигабайтный файл? :)

> А если там гигабайтный файл? :)

Дак блоками же читаем. Памяти больше, чем размер блока, не съест.

Выводы делайте сами.

вывод №1 TC не умеет писать тесты на производительность

вывод №2 TC не слишком разбирается с тем, что хочет померять

итог : некорректное сравнение по скорости кислого и мягкого

Так будет сложнее обрабатывать: что, если у вас начало строки с разделителем попадет на конец блока? Как вы его будете выделять, не считывая следующий блок?

> итог : некорректное сравнение по скорости кислого и мягкого

Аргументировать сможем?

> Так будет сложнее обрабатывать: что, если у вас начало строки с разделителем попадет на конец блока? Как вы его будете выделять, не считывая следующий блок?

Это лишь вопрос реализации. Зато сам по себе такой метод работает быстрее.

такой метод работает быстрее

А теперь добавь сюда логику, которая была в exim.

Аргументировать сможем?

1) вы наверное думаете, что реализовали блочное чтение..

2) что fread и fgetc имеют исключительное отношение в ФС

3) что они алгоритмически применяются в одинаковых случаях и надо выбрать кто из них быстрее.

4) и что погрешности в секунды роли не играют

> и что погрешности в секунды роли не играют

Играют, но мне лень.

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

Они могут применяться в одинаковых случаях.

что fread и fgetc имеют исключительное отношение в ФС

Это Вы себе придумали.

вы наверное думаете, что реализовали блочное чтение

А вот с этим спорить не буду, думаю.

>Тем не менее, fgetc всё равно показал свою неэффективность.

Это не неэффективность, это вполне объяснимая разница.

И fread, и fgetc лочат/разлочивают дескриптор на время работы. И та, и другая юзают один и тот же буфер при чтении. И та, и другая дочитывают в этот буфер, когда выходят за пределы. Просто fgetc вызывается на порядок больше раз.

При этом, как тут уже подметили, некоторые вещи можно быстро и удобно реализовать с fgetc, а не мудохаться с ручной буферизацией.

а не мудохаться с ручной буферизацией.

Можно просто написать оболочку. Что-нибудь вроде:

const int max_buf_size = 512;
int buf_size = -1;
char buf[max_buf_size];
int buf_n = 0;



bool myfeof(FILE* f)
{
	return (feof(f) && (buf_n>=buf_size));
}

char myfgetc(FILE* f)
{
	if (buf_n<buf_size) return buf[buf_n++];
	else
	if (!feof(f))
	{
		buf_size = fread(buf,1,max_buf_size,f);
		buf_n = 0;
		return buf[buf_n++];
	}

	return 0;

}

Это всё равно будет работать быстрее. По крайней мере с ФС.

> Это не неэффективность, это вполне объяснимая разница.

Нет уж, не передёргивайте, это неэффективность, вызванная вполне объяснимой разницей.

> fread(buf,1,max_buf_size,f);

fread(buf,1,

1

...

Судя по тестам windows победил.

Ну правильно. max_buf_size элементов, каждый по 1 байту. Да и вообще я не говорил «юзайте мою реализацию». Я говорил о самой идее.

Ты strace запускать пробовал?

> Судя по тестам windows победил.

Просто винты разные =)

И? Первый size - это размер типа данных, в байтах.

> Ты strace запускать пробовал?

На предмет?

Посмотреть что происходит, когда вызывается fgetc

> Посмотреть что происходит, когда вызывается fgetc

Да как бы пока что меня вполне устроили результаты тестирования и с blackbox. Но посмотрю.

> это неэффективность

Это лишь неэффективность чтения сырых данных. А как только понадобится посимвольный разбор данных, разница резко уменьшится.

Ок. Можешь добавить перед while строчку

setvbuf(f, buf,_IOFBF, n);

И померять еще раз

вы наверное думаете, что реализовали блочное чтение

А вот с этим спорить не буду, думаю.

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

И вместо fgetc использовать getc.

> setvbuf(f, buf,_IOFBF, n); И померять еще раз

Не помогло. Скорость немного выросла, на пару МБ/сек.

> И вместо fgetc использовать getc.

Что-то толку всё равно нет, скорость не меняется.

позволю себе немного продолжить, а то newbie`сы ещё решат что надо все щели пихать fread и избегать fgetc и кол-во быдло кода резко возрастёт.

то что измеряет уважаемый TC реально зовётся кривой двойной буферизацией и ни разу не блочным чтением. На примере - если в приведённом коде, до тестов считать например 157 байт из файла (вполне жизненная ситуация - например чтение некоего заголовка), то замеры тестов с fgetc остануться в пределах погрешности измерений, а замеры заглушки через fread испортятся.

Вот таким вот простым движением TC получил метод с непредсказуемым поведением. Пытаясь это исправить придётся обращать внимание на выравнивание буферов памяти и блоков диска, а потом с удивлением увидеть что скорость теряется на переносе неких кусочков между вашим буфером и буфером FILE и что полученный код до удивления похож на код fread за отсутсвием обработки сигналов и ошибок, гибкости и переносимости.

Ёпрст...fread, fgetc прикладные библиотечные функции, скрывающие за собой детали реализации и взаимодействие с системой. Если надо получить байт из потока, то юзается fgetc, если заранее известное кол-во байт/структур/блоков то fread, если строка нужна - то fgets. Во всех них нормально сделана буферизация.

А если сцуко программист прикладник, которому показалось что 100500 вызовов fgetc стоит заменить тем же числом вызовов (зато своих)функций и 1-м fread, будет хреначить ворох кода, втащит системно-зависимые вещи, да ещё и дублируя функции стандартных библиотек, то он как минимум неграмотное @#$@.

p.s. если скорость чтения/записи становиться критичной то её реализуют по возможности через mmap, а иначе через read/write

Хорошо, сдвинем на 157 байт.

буфер | размер | время | мб/сек|
-------------------------------|
128   | 1465   | 18    | 81.4  |
256   | 1562   | 18    | 86.8  |
512   | 1565   | 23    | 68.0  |
1024  | 2205   | 21    | 105   |
2048  | 1463   | 19    | 77    |
4096  | 1561   | 19    | 82.1  |
8192  | 1471   | 19    | 77.4  |
-------------------------------|

О боже, оно не стало медленнее! Да это же чудо! Или кое-кому надо аккуратнее с потоками желчи.

> заменить тем же числом вызовов (зато своих)

Откройте для себя inline.