Re: Micro-optimizations to avoid some strlen calls.

From: David Rowley <dgrowleyml(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: Micro-optimizations to avoid some strlen calls.
Date: 2021-07-21 10:44:17
Message-ID: CAApHDvoY4E3CLfk84ufn4xfhhmfbQ1A_Xs_s0FUfCCiyUAH_xQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 20 Jul 2021 at 10:49, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
> There are some places, where strlen can have an overhead.
> This patch tries to fix this.

I'm with Michael and David on this.

I don't really feel like doing;

- snprintf(buffer, sizeof(buffer), "E%s%s\n",
+ buflen = snprintf(buffer, sizeof(buffer), "E%s%s\n",
_("could not fork new process for connection: "),

is a good idea. I'm unsure if you're either not aware of the value
that snprintf() returns or just happen to think an overflow is
unlikely enough because you're convinced that 1000 chars are always
enough to fit this translatable string. I'd say if we were 100%
certain of that then it might as well become sprintf() instead.
However, I imagine you'll struggle to get people to side with you that
taking this overflow risk would be worthwhile given your lack of any
evidence that anything actually has become meaningfully faster as a
result of any of these changes.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ajin Cherian 2021-07-21 10:58:45 Re: logical replication empty transactions
Previous Message Bharath Rupireddy 2021-07-21 10:22:39 Re: Printing backtrace of postgres processes