Re: Avoid overhead with fprintf related functions - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Avoid overhead with fprintf related functions
Date
Msg-id CAEudQAo+BO0h1ZgMHhZT0ZXK1WS+f9DEb6d6u4MCoiMgepR9dQ@mail.gmail.com
Whole thread Raw
In response to Re: Avoid overhead with fprintf related functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Em sex., 9 de set. de 2022 às 18:53, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
Ranier Vilela <ranier.vf@gmail.com> writes:
> Em sex., 9 de set. de 2022 às 13:20, Nathan Bossart <
> nathandbossart@gmail.com> escreveu:
>> 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.

> 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

That is most certainly not enough gain to justify a large amount
of code churn.  In fact, given that this is probably pretty
platform-dependent and you've checked only one platform, I don't
think I'd call this a sufficient case for even a one-line change.
Of course, base these changes not on performance gain, but on correct style and increased security.
But out-vote is out-vote, case closed.

Regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Introduce wait_for_subscription_sync for TAP tests
Next
From: Thomas Munro
Date:
Subject: Re: Introduce wait_for_subscription_sync for TAP tests