From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Avoid overhead with fprintf related functions |
Date: | 2022-09-09 21:49:32 |
Message-ID: | CAEudQAowbxdoTj2AOsAwwOzXUMZnZ8b8_hmbpRtQfahGP9i44Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Em sex., 9 de set. de 2022 às 10:45, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
escreveu:
> 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.
> 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).
>
> Patch attached.
> This pass check-world.
>
Rechecked for the hundredth time.
One typo.
regards,
Ranier Vilela
Attachment | Content-Type | Size |
---|---|---|
v1-fprintf_fixes.patch | text/x-patch | 66.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-09-09 21:53:54 | Re: Avoid overhead with fprintf related functions |
Previous Message | Tom Lane | 2022-09-09 21:45:43 | Re: Introduce wait_for_subscription_sync for TAP tests |