Re: inline newNode()
От | Bruce Momjian |
---|---|
Тема | Re: inline newNode() |
Дата | |
Msg-id | 200210092115.g99LFNt26929@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: inline newNode() (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: inline newNode()
|
Список | pgsql-patches |
Peter Eisentraut wrote: > Tom Lane writes: > > > If you use memset() instead of MemSet(), I'm afraid you're going to blow > > off most of the performance gain this was supposed to achieve. > > Can someone explain to me why memset() would ever be better than MemSet()? I am surprised MemSet was ever faster than memset(). Remember, MemSet was done only to prevent excessive function call overhead to memset(). I never anticipated that a simple while() loop would be faster than the libc version, especially ones that have assembler memset versions, but, for example on Sparc, this is true. I looked at the Sparc assembler code and I can't see why MemSet would be faster. Perhaps someone can send over the Sparc assembler output of MemSet on their platform and I can compare it to the Solaris assembler I see here. In fact, they can probably disassemble a memset() routine there and see exactly what I see. > Also, shouldn't GCC (at least 3.0 or later) inline memset() automatically? Not sure, but yes, that may be true. I think it requires a high optimizer level, perhaps higher than our default. > What's the result of using -finline (or your favorite compiler's > inlining flag)? Yes, that would be it. > And has someone wondered why the GEQO code needs so many new nodes? > Perhaps a more lightweight data representation for internal use could be > appropriate? I assume the GEQO results he is seeing is only for a tests, and that the macro version of newNode will help in all cases. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-patches по дате отправления: