Re: MemSet inline for newNode
От | Tom Lane |
---|---|
Тема | Re: MemSet inline for newNode |
Дата | |
Msg-id | 23463.1036984232@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: MemSet inline for newNode (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: MemSet inline for newNode
|
Список | pgsql-patches |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Tom Lane wrote: >> But with any reasonably smart compiler, those *will* be the same because >> the compiler can do constant-folding (ie, it knows i is 256 when control >> reaches the MemSet). Pushing the MemSet into MemoryContextAlloc >> eliminates the possibility of knowing the size argument's value. > Yes, however, I am not seeing that getting optimized with gcc 2.95 -O2. You aren't? I just checked gcc 2.95.3 on HPPA; it definitely propagates the constant at -O2. > Well, the palloc0 use by newNode was a performance boost, as tested by > Neil Conway. Without palloc0, there was no way to inline newNode. But your patch as committed does NOT inline newNode, in fact it does the exact opposite: the MemSet macro is removed from the callsite. > I made a new version that did the alignment test of start and len in one > pass: I thought the point of this exercise was to eliminate the alignment test altogether, by making it doable at compile time. IIRC, the upshot of the prior discussion was to keep the MemSet calls at the call site and to eliminate the alignment test on the pointer by special-casing palloc0 (essentially, wiring into the macro the assumption that palloc's returned pointer will be suitably aligned). regards, tom lane
В списке pgsql-patches по дате отправления: