a_ogawa <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend