Re: Faster StrNCpy

Поиск
Список
Период
Сортировка
От mark@mark.mielke.cc
Тема Re: Faster StrNCpy
Дата
Msg-id 20061003141257.GA16947@mark.mielke.cc
обсуждение исходный текст
Ответ на Re: Faster StrNCpy  ("Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.at>)
Ответы Re: Faster StrNCpy  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Oct 03, 2006 at 01:56:57PM +0200, Zeugswetter Andreas DCP SD wrote:
> 
> > > > I'm still interested to experiment with MemSet-then-strlcpy for 
> > > > namestrcpy, but given the LENCPY results this may be a loser too.
> > > Um, why not strlcpy then MemSet the rest ?
> > That's what strncpy() is supposed to be doing.

> Yes, but it obviously does not in some ports, and that was the main
> problem as I interpreted it.

I think re-writing libc isn't really a PostgreSQL goal.

strlcpy() is theoretically cheaper than strncpy() as it is not
required by any standard to do as much work. memcpy() is cheaper
because it can be more easily parallelized, and can increment
multiple bytes with each loop interval, as it does not need to
slow down to look for a '\0' in each byte.

strlcpy() than memset() the remaining is strncpy(). If you are
suggesting that a moderately tuned version of strncpy() be used
in the ports directory, this is an option, but it can't be
faster than strlcpy(). It's not possible. It would come down to
whether there was a security requirements that the last bytes
were '\0' or not. I haven't seen anybody mention this as a
requirement.

Cheers,
mark

-- 
mark@mielke.cc / markm@ncf.ca / markm@nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada
 One ring to rule them all, one ring to find them, one ring to bring them all                      and in the darkness
bindthem...
 
                          http://mark.mielke.cc/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCHES] Bad bug in fopen() wrapper code
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCHES] Generic Monitoring Framework with DTrace patch