From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(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 21:45:31 |
Message-ID: | CAEudQAp_GWn10BNFwRpNgERGwJy2ZanUBBrBO+_By1akamkujw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Em sex., 9 de set. de 2022 às 13:20, Nathan Bossart <
nathandbossart(at)gmail(dot)com> escreveu:
> 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.
>
Simple benchmark with David sort example.
1. make data
create table t (a bigint not null, b bigint not null, c bigint not
null, d bigint not null, e bigint not null, f bigint not null);
insert into t select x,x,x,x,x,x from generate_Series(1,140247142) x; --
10GB!
vacuum freeze t;
2. client run
\timing on
\pset pager off
select * from t limit 1000000;
head:
Time: 418,210 ms
Time: 419,588 ms
Time: 424,713 ms
fprintf patch:
Time: 416,919 ms
Time: 416,246 ms
Time: 416,237 ms
regards,
Ranier Vilela
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-09-09 21:45:43 | Re: Introduce wait_for_subscription_sync for TAP tests |
Previous Message | Masahiko Sawada | 2022-09-09 21:33:51 | Re: Introduce wait_for_subscription_sync for TAP tests |