Re: refactoring - share str2*int64 functions

From: Andres Freund <andres(at)anarazel(dot)de>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: refactoring - share str2*int64 functions
Date: 2019-07-17 18:21:09
Message-ID: 20190717182109.gnvjyndleptqtwcc@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-07-17 12:04:32 +0900, Michael Paquier wrote:
> On Tue, Jul 16, 2019 at 01:18:38PM -0700, Andres Freund wrote:
> > I'd probably also just use the implementation we have for signed
> > integers (minus the relevant negation and overflow checks, obviously) -
> > it's a lot faster, and I think there's value in keeping the
> > implementations in sync.
>
> You mean that it is much faster than the set of wrappers for strtol
> than we have? Is that because we don't care about the base?

Yes: https://www.postgresql.org/message-id/20171208214437.qgn6zdltyq5hmjpk%40alap3.anarazel.de

Not caring about the base is one significant part, that removes a fair
bit of branches and more importantly allows the compiler to replace
divisions with much faster code (glibc tries to avoid the division too,
with lookup tables, but that's still expensive). Additionally there's
also some locale awareness in strtoll etc that we don't need. It's also
plainly not that well implemented at least in glibc and musl.

Having an implementation that reliably works the same across all
platforms is also advantageous.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-07-17 18:28:09 Re: refactoring - share str2*int64 functions
Previous Message Tom Lane 2019-07-17 18:20:24 Re: Change ereport level for QueuePartitionConstraintValidation