Re: snprintf.c hammering memset() - Mailing list pgsql-hackers

From Andres Freund
Subject Re: snprintf.c hammering memset()
Date
Msg-id 20181002005319.uq56aaiwsalnjllp@alap3.anarazel.de
Whole thread Raw
In response to Re: snprintf.c hammering memset()  (Andres Freund <andres@anarazel.de>)
List 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


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: snprintf.c hammering memset()
Next
From: Tom Lane
Date:
Subject: Re: snprintf.c hammering memset()