Re: Rethinking MemoryContext creation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Rethinking MemoryContext creation
Date
Msg-id 9726.1513009650@sss.pgh.pa.us
Whole thread Raw
In response to Rethinking MemoryContext creation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Rethinking MemoryContext creation  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Re: Rethinking MemoryContext creation  (Simon Riggs <simon@2ndquadrant.com>)
List 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 by date:

Previous
From: Everaldo Canuto
Date:
Subject: Re: proposal: alternative psql commands quit and exit
Next
From: David Fetter
Date:
Subject: Re: proposal: alternative psql commands quit and exit