Re: snprintf.c hammering memset()

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Mateusz Guzik <mjguzik(at)gmail(dot)com>
Subject: Re: snprintf.c hammering memset()
Date: 2018-10-02 00:53:19
Message-ID: 20181002005319.uq56aaiwsalnjllp@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-10-01 17:46:55 -0700, Andres Freund wrote:
> On 2018-10-01 20:19:16 -0400, Tom Lane wrote:
> > argtypes is only a small part of the stack-space issue, there's also
> > argvalues which is (at least) twice as big. I don't think second-guessing
> > the compiler about the most efficient representation for an enum is
> > going to buy us much here.
>
> Sure, but argvalues isn't zeroed out. As long as the memory on the
> stack isn't used (as is the case for most of arvalues elements), the
> size of the stack allocation doesn't have a significant efficiency
> impact - it's still just an %rsp adjustment. If we're going to continue
> to zero out argtypes, it's sure going to be better to zero out 16 rather
> than 64bytes (after limiting to 16 args).

Btw, I don't think any common compiler optimizes common enum sizes for
efficiency. Their size is part of the struct layout, so doing so would
not generally be trivial (although you get to larger enums if you go
above either INT32_MAX or UINT32_MAX element values, but ...).

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-10-02 00:57:34 Re: snprintf.c hammering memset()
Previous Message Andres Freund 2018-10-02 00:46:55 Re: snprintf.c hammering memset()