Re: Rethinking MemoryContext creation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Rethinking MemoryContext creation
Дата
Msg-id 9726.1513009650@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Rethinking MemoryContext creation  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Rethinking MemoryContext creation  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Re: Rethinking MemoryContext creation  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
I wrote:
> While fooling around with a different problem, I got annoyed at how slow
> MemoryContext creation and deletion is.

Looking at this some more, there's another micro-optimization we could
make, which is to try to get rid of the strlen+strcpy operations needed
for the context name.  (And yes, I'm seeing those show up in profiles,
to the tune of a couple percent of total runtime in some examples.)

For a *very* large majority of the callers of AllocSetContextCreate,
the context name is a simple C string constant, so we could just store
the pointer to it and save the space and cycles required to copy it.
This would require providing a separate API for the few callers that are
actually passing transient strings, but that's easy enough.  I envision
AllocSetContextCreate becoming a wrapper macro for
"AllocSetContextCreateExtended", which'd take a flag argument specifying
whether the context name needs to be copied.

However, unless we want to run around and touch all the ~ 150 calls
with constant arguments, we'd have to set things up so that the default
behavior for AllocSetContextCreate is to not copy.  This risks breaking
callers in extensions.  Not entirely sure if it's worth that --- any
thoughts?

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Everaldo Canuto
Дата:
Сообщение: Re: proposal: alternative psql commands quit and exit
Следующее
От: David Fetter
Дата:
Сообщение: Re: proposal: alternative psql commands quit and exit