LINUX.ORG.RU

fprintf vs sprintf+fputs


0

0

По моим тестам fprintf медленнее fputs+sprintf, то есть быстрее вывести в память всё sprintf-ами и вывести затем в файл одним fputs. Однако на практике в моем приложении это не всегда подтверждается (есть места где fprintf оказывается быстрее sprintf+fputs).

1. От чего зависит скорость работы fprintf (при стандартных размерах буферов, т.е. без игр с setvbuf), и разная ли будет относительная скорость работы fprintf/sprintf+fputs для разных платформ? Или я совсем не прав, потому что тесты выводили информацию на stderr, который я сливал в /dev/null (вроде stderr запрещено буферизовать).

2. Стоит ли fputs заменить на fwrite в случае если sprintf+fputs все-таки лучше?

По коду: рассматриваю использовать ли Nx sprintf+N/50x fputs или Nx fprintf, размер порции частовыводимой информации в файл от 5 до 32 байт (N/50 - это неподтвержденная моя прикидка).

P.S. Поделитесь опытом. Да, программа обрабатывает входящий поток миллионов записей... (wc -l для типового файла выдал 6'896'149).

★★★★★

snprintf пока не предлагать, там все через a-la buf[8192];fscanf (... %8191s ... buf) делается :-)

saper ★★★★★
() автор топика

На ту же тему, но немного не то, пример:
fprintf(ifile, "<tr><th>%s<th>00:00<th>01:00<th>02:00<th& gt;03:00<th>04:00<th>05:00<th>06:00<th>07:00<th>08 :00<t
h>09:00<th>10:00<th>11:00<th>12:00<th>13:00<th> 14:00<th>15:00<th>16:00<th>17:00<th>18:00<th>19:00 <th>20:00<th>21:
00<th>22:00<th>23:00<th>%s\n", loc->DsT, loc->Bytes);

Можно и так:
short int i;

fprintf(ifile, "<tr><th>%s", loc->DsT);
for (i = 0; i < 25; i++) { // можно и while (i++ < 25), а выше short int i = 0;
fprintf(ifile, "<th>%02hd:00", i);
}
fprintf(ifile, "<th>%s\n", loc->Bytes);

Или так:
short int i;
char tbuf[MAXLEN];

sprintf(tbuf, "<tr><th>%s", loc->DsT);
for (i = 0; i < 25; i++) {
sprintf(&tbuf[strlen(tbuf)], "<th>%02hd:00", i);
}
sprintf(&tbuf[strlen(tbuf)], "<th>%s\n", loc->Bytes);
fputs(tbuf, ifile);

saper ★★★★★
() автор топика
Ответ на: комментарий от saper

offtop: накой `short int'?

где-то, когда-то читал, что для сщётчика циклов желательнее брать базовый тип процессора -- т.е. `int' (в частности из-за скорости), а все эти экономии на спичках с `shot' мало того, что не приносят желательного результата, так могут ещё и боком выйти (хуже оптимизируется и т.д.)

если не так -- поправте

beastie ★★★★★
()

>1. От чего зависит скорость работы fprintf

От наличия в строке модифиакторов в т.ч. Если их нет, то умный gcc вообще вместо fprintf() будет fputs() вызывать.

php-coder ★★★★★
()
Ответ на: комментарий от php-coder

> От наличия в строке модифиакторов в т.ч. Если их нет, то умный gcc вообще вместо fprintf() будет fputs() вызывать.

Больше интересует что выбрать из fprintf и sprintf+fputs...

saper ★★★★★
() автор топика

>По моим тестам В /dev/null тесты. Тесты бывают далеки от реальности. man gprof.

>P.S. Поделитесь опытом. Да, программа обрабатывает входящий поток миллионов записей... (wc -l для типового файла выдал 6'896'149).

У тебя есть данные профайлера, которые показывают что тормозным местом является именно вывод, а не алгоритм обработки? Если нет, тогда

fprintf(f,"hello, %s\n",something); одна строчка

snprintf(buf,sizeof(buf), "hello, %s", something); fputs(buf,f);

две строчки.

И одна строчка в два раза лучше двух.

Повторюсь - если профайлер не показывает что output - самое медленное место твоей проги , то оставь эти мысли с XXprintf'ами.

anonymous
()
Ответ на: комментарий от anonymous

Спасибо за напоминание, gprof использую :-)

saper ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.