Re: snprintf.c hammering memset()

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: snprintf.c hammering memset()
Дата
Msg-id 20181002005319.uq56aaiwsalnjllp@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: snprintf.c hammering memset()  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: snprintf.c hammering memset()
Следующее
От: Tom Lane
Дата:
Сообщение: Re: snprintf.c hammering memset()