Re: Avoid overhead with fprintf related functions

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoid overhead with fprintf related functions
Date: 2022-09-09 16:19:56
Message-ID: 20220909161956.GA2254174@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 09, 2022 at 10:45:37AM -0300, Ranier Vilela wrote:
> 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).

I agree with David [0]. But if you can demonstrate a performance gain,
perhaps it's worth considering a subset of these changes in hot paths.

[0] https://postgr.es/m/CAApHDvp2THseLvCc%2BTcYFBC7FKHpHTs1JyYmd2JghtOVhb5WGA%40mail.gmail.com

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2022-09-09 16:34:15 Re: Add tracking of backend memory allocated to pg_stat_activity
Previous Message Justin Pryzby 2022-09-09 16:07:41 Re: pg_upgrade generated files in subdir follow-up