Avoid overhead with fprintf related functions
| От | Ranier Vilela |
|---|---|
| Тема | Avoid overhead with fprintf related functions |
| Дата | |
| Msg-id | CAEudQAoXozYNsx3T-PZFk-QraRKYHRRarOhF4C2GuTfrct3g_A@mail.gmail.com обсуждение исходный текст |
| Ответы |
Re: Avoid overhead with fprintf related functions
Re: Avoid overhead with fprintf related functions |
| Список | pgsql-hackers |
Based on work in [1].
According to https://cplusplus.com/reference/cstdio/fprintf/
The use of fprintf is related to the need to generate a string based on a format, which should be different from "%s".
Since fprintf has overhead when parsing the "format" parameter, plus all the trouble of checking the va_arg parameters.
I think this is one of the low fruits available and easy to reap.
By replacing fprintf with its equivalents, fputs and fputc,
we avoid overhead and increase security [2] and [3].
The downside is a huge big churm, which unfortunately will occur.
But, IHMO, I think the advantages are worth it.
Patch attached.
According to https://cplusplus.com/reference/cstdio/fprintf/
The use of fprintf is related to the need to generate a string based on a format, which should be different from "%s".
Since fprintf has overhead when parsing the "format" parameter, plus all the trouble of checking the va_arg parameters.
I think this is one of the low fruits available and easy to reap.
By replacing fprintf with its equivalents, fputs and fputc,
we avoid overhead and increase security [2] and [3].
The downside is a huge big churm, which unfortunately will occur.
But, IHMO, I think the advantages are worth it.
Note that behavior remains the same, since fputs and fputc do not change the expected behavior of fprintf.
A small performance gain is expected, mainly for the client, since there are several occurrences in some critical places, such as (usr/src/fe_utils/print.c).
This pass check-world.
regards,
Ranier Vilela
Вложения
В списке pgsql-hackers по дате отправления: