Re: inline newNode()
От | Bruce Momjian |
---|---|
Тема | Re: inline newNode() |
Дата | |
Msg-id | 200210100456.g9A4u4U18738@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: inline newNode() (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: inline newNode()
|
Список | pgsql-patches |
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Can someone explain to me why memset() would ever be better than MemSet()? > > memset() should *always* be faster than any C-coded implementation > thereof. Any competent assembly-language writer can beat C-level > locutions, or at least equal them, if he's willing to expend the > effort. You would think so. I am surprised too. > I've frankly been astonished at the number of platforms where it > seems memset() has not been coded with an appropriate degree of > tenseness. The fact that we've found it useful to invent MemSet() > is a pretty damning indictment of the competence of modern C-library > authors. Remember, MemSet was invented only to prevent function call overhead, and on my BSD/OS system, len >= 256 is faster with the libc memset(). It is a fluke we found out that MemSet is faster that memset for all lengths on some platforms. > Or am I just stuck in the obsolete notion that vendors should provide > some amount of platform-specific tuning, and not a generic library? What really surprised me is that MemSet won on Sparc, where they have an assembler language version that looks very similar to the MemSet loop. In fact, I was the one who encouraged BSD/OS to write assembler language verions of many of their str* and mem* functions. -- 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 по дате отправления: