Re: RFC: list API / memory allocations

Andres Freund <andres(at)anarazel(dot)de> writes:
> In many scenarios memory allocation is one of the top 3 functions showing up
> in profiles. Looking at hierarchical profiles (-fno-omit-frame-pointer) at least
> during parsing, planning and executor startup most of that is spent around the
> list API.

> Many - especially in the parse-analyze phase - of those allocations can be
> avoided because the lists are immutable and their size is known upfront.

The fundamental problem with all of those proposals is that now you have
some lists in the system that aren't like other lists, and will result
in dumping core if the wrong sorts of operations are applied to them.
I don't particularly care for introducing that kind of fragility into
the system in return for marginal speed gains. I'm not impressed by
Asserts showing that no such thing happens in the cases you tested;
the test coverage won't be complete, and even if it is, innocent-looking
code changes later on could create new problems.

Now, if you could do something that *doesn't* restrict what operations
could be applied to the lists, that would be good.

I've wished for a long while that we could allocate the list header and
the first list cell in a single palloc cycle. This would basically
require getting list_delete_cell to refrain from pfree'ing a cell that
got allocated that way, which is easy as long as you have the list
header at hand, but what happens if the list is later concat'd to
another? A subsequent delete operation would be referring to the other
list header and would come to the wrong conclusion.

While thinking about this just now, it occurred to me that maybe the
issues could be dodged if the cell, not the header, were first in the
combined palloc block. list_concat is then no longer a problem, as long
as it doesn't try to throw away the second list's header. But I haven't
thought long enough to be sure how well that would work.

regards, tom lane