Re: AllocSetReset improvement

a_ogawa <a_ogawa(at)hi-ho(dot)ne(dot)jp> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Hmm. It doesn't seem like this could be a big win overall. It's not
>> possible to save a whole lot of cycles inside AllocSetReset, because if
>> there isn't anything for it to do, it should fall through pretty quickly
>> anyway.

> I thought that I was able to avoid MemSet in AllocSetReset.

> MemSet(set->freelist, 0, sizeof(set->freelist));

True, but the memset is only zeroing a dozen or so pointers, so there's
not *that* much to it.

It might be worth changing it to MemSetAligned --- should be safe on any
architecture I can think of, and would save at least a few instructions.

>> And I'm worried about adding even a small amount of overhead to
>> palloc/pfree --- on the vast majority of the profiles I look at, those
>> are more expensive than AllocSetReset.

> I don't worry about palloc. Because overhead increases only when malloc
> is executed in AllocSetAlloc. But I'm wooried about pfree, too. However,
> when palloc/pfree was executed many times, I did not see a bad influence.

In most of the tests I've looked at, palloc/pfree are executed far more
often than AllocSetReset, and so adding even one instruction there to
sometimes save a little work in AllocSetReset is a bad tradeoff. You
can't optimize to make just one test case look good.

I have another idea though: in the case you are looking at, I think
that the context in question never gets any allocations at all, which
means its blocks list stays null. We could move the MemSet inside the
"if (blocks)" test --- if there are no blocks allocated to the context,
it surely hasn't got any chunks either, so the MemSet is unnecessary.
That should give us most of the speedup without any extra cost in
palloc/pfree.

regards, tom lane