Em sex., 9 de set. de 2022 às 13:20, Nathan Bossart < nathandboss...@gmail.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
