Re: fprintf && write

From

Valentin Nechayev ()

To

Boris Rudakov ()

Date

2003-06-04T12:24:22Z

Area

CARBON.COPY

 * Forwarded from area 'RU.UNIX.PROG'
From: netch@segfault.kiev.ua (Valentin Nechayev)

>>> Boris Rudakov wrote:

 AM>>   fprintf(out, "%s", buffer);
BR> Не вижу ни малейшего смысла в подобных конструкциях. Кишки xrintfxxx заняты
BR> тем, что интерпретируют единственный "%s" и тупо перекачивают buffer в out.
BR> Накладные расходы в этой и подобных конструкциях несущественны, но... Зачем они
BR> когда можно и без них ?

Можно. Главное - не подставить неизвестную строку в формат в fprintf. Лучше -
fputs().

Кстати, gcc3, например, в hosted режиме переведёт это в fputs() сам.

BR> Я в таких случаях пишу данные непосредственно туду куда нужно, избегая лишних
BR> переписываний во внутренних буфферах.
BR> 
BR> Чен'ть типа write(out, .....);

write() - только в том случае если stdio буфер был перед этим успешно
сброшен (fflush()). Иначе начнётся каша между буферами.

BR> 1. write - синхронный блокирующий вызов (или я не прав ?). Но, как бы то ни
BR> было, ты скармливаешь ему весь буффер. Если бы он у тебя выводил не весь
BR> буффер, а часть - ты бы давно уже заметил что твой код неправилен и поправил бы
BR> приращение буфера и декремент длины. Значит - write у тебя пишет все одним
BR> махом. Значит - глюк не в нем.

Логично. ;)
Кстати - 2All - вот отличный пример логики в поиске ошибок.

BR> Моя теория такова (еще раз шаркну ножкой что я не юниксоид, но основные
BR> принципы едины):
BR> 
BR> * Твой код делает два системных вызова.
BR> 
BR> * Твой код выводит все за одну итерацию (иначе ты бы уже заметил ошибки в нем).
BR> Итого - ты делаешь ровно один select и ровно один write.
BR> 
BR> * "Меня терзают смутные сомнения" что fprintf же делает только один - синхроный
BR> блокирующий write. И делает только один write (правда х.з. что он делает при
BR> переполнении внутренних буфферов при форматировании строки - может быть он
BR> делает серию write по мере их заполнения; однако, думаю что в твоем случае ему
BR> там хватает одного write).

Скорее всего, только один. И то - не всегда. Стандартная буферизация идёт
кусками, кажется, по 4K. Вряд ли все строки столь длинные.

BR> * Так же меня "терзают смутные сомнения" что select - дорогой вызов, дороже
BR> write.

Если номер дескриптора не сильно велик, то select действительно не должен
быть дороже write().

BR> Таким образом, сдается мне что двукратное замедление вызвано тем, что ты в два
BR> раза чаще беспокоишь ядро системы :)


-netch-
--- ifmail v.2.15dev5
 * Origin: Dark side of the coredump (2:5020/400)