Re: Performance improvements for src/port/snprintf.c

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru>
Subject: Re: Performance improvements for src/port/snprintf.c
Date: 2018-10-03 16:14:54
Message-ID: 20181003161454.ozeioucsimjg5g6m@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-10-03 12:07:32 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > FWIW, it seems that using a local buffer and than pstrdup'ing that in
> > float8out_internal is a bit faster, and would probably save a bit of
> > memory on average:
> > float8out using sprintf via pg_double_to_string, pstrdup:
> > 15370.774
> > float8out using strfromd via pg_double_to_string, pstrdup:
> > 13498.331
>
> [ scratches head ... ] How would that work? Seems like it necessarily
> adds a strlen() call to whatever we'd be doing otherwise. palloc isn't
> going to be any faster just from asking it for slightly fewer bytes.
> I think there might be something wrong with your test scenario ...
> or there's more noise in the numbers than you thought.

I guess the difference is that we're more likely to find reusable chunks
in aset.c and/or need fewer OS allocations. As the memory is going to
be touched again very shortly afterwards, the cache effects probably are
neglegible.

The strlen definitely shows up in profiles, it just seems to save at
least as much as it costs.

Doesn't strike me as THAT odd?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bossart, Nathan 2018-10-03 16:20:42 Re: Add SKIP LOCKED to VACUUM and ANALYZE
Previous Message Tom Lane 2018-10-03 16:07:32 Re: Performance improvements for src/port/snprintf.c