Bruce Momjian <[EMAIL PROTECTED]> writes:
> This is from October 2006. Is there a TODO here?
I think we had decided that the code that's in there is fine.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to in
This is from October 2006. Is there a TODO here?
---
Tom Lane wrote:
> I did a couple more tests using x86 architectures. On a rather old
> Pentium-4 machine running Fedora 5 (gcc 4.1.1, glibc-2.4-11):
>
> $ gcc -O3 -std=
> "ZA" == Zeugswetter Andreas DCP SD <[EMAIL PROTECTED]> writes:
ZA> Yes, but it obviously does not in some ports, and that was the
ZA> main problem as I interpreted it.
strncpy is part of POSIX; I highly doubt anyone gets it wrong. Getting
sane semantics from it does require manually writing
[EMAIL PROTECTED] writes:
> ... 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.
I think it is a requirement for namestrcpy (because the result might end
up on disk), but not elsewhere.
"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
>> 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 ?
Two reasons:
* The main point is to do the zeroing using
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(
> > > 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
On Tue, Oct 03, 2006 at 10:24:10AM +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 b
> 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 ?
Andreas
---(end of broadcast)---
TIP 4: Have you searched our list ar
Tom,
FWIW, Tom Daly did some SpecJAppserver runs on the latest snapshot and
didn't show any reduction in text parsing overhead. Unfortunately, he's
gone on vacation now so I can't get details.
I'm going to try to set up some tests using TPCE to see if it's affected.
--Josh
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > You'll notice that it iterates once per char. Between that and the
> > strlen() call in Tom's version, not sure which is the lesser evil.
>
> Yeah, I was wondering that too. My code would require two scans of the
> source string (o
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > A wholesale replacement of strncpy() calls is probably worth doing --
> > replacing them with strlcpy() if the source string is NUL-terminated,
> > and I suppose memcpy() otherwise.
>
> What I'd like to do immediately is put in strlcpy(
Tom,
Yes, the clients are using the V3 protocol and prepared statements.
David
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Mon 10/2/2006 2:09 PM
To: Strong, David
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Faster StrNCpy
"Strong,
"Strong, David" <[EMAIL PROTECTED]> writes:
> Obviously, different copy mechanisms suit different data sizes. So, I
> added a little debug to the strlcpy () function that was added to
> Postgres the other day. I ran a test against Postgres for ~15 minutes
> that used 2 client backends and the BG wr
I did a couple more tests using x86 architectures. On a rather old
Pentium-4 machine running Fedora 5 (gcc 4.1.1, glibc-2.4-11):
$ gcc -O3 -std=c99 -DSTRING='"This is a very long sentence that is expected to
be very slow."' -DN="(1024*1024)" -o x x.c y.c strlcpy.c
NONE:786305 us
MEMCPY
On Mon, 2 Oct 2006, Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
Just the test on IA64 (Itanium2, 1.6Ghz, 8Gb memory). The results seem to
be quite different:
What libc are you using exactly? Can you try it with the unrolled
strlcpy I posted?
glibc 2.3.5 , gcc 3.4.4
my
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> Just the test on IA64 (Itanium2, 1.6Ghz, 8Gb memory). The results seem to
> be quite different:
What libc are you using exactly? Can you try it with the unrolled
strlcpy I posted?
In glibc-2.4.90, there seem to be out-of-line assembly code
implem
Mark, Tom,
Just the test on IA64 (Itanium2, 1.6Ghz, 8Gb memory). The results seem to
be quite different:
[EMAIL PROTECTED]:~/test$ gcc -O3 -std=c99 -DSTRING='"This is a very long sentence that is
expected to be very slow."' -DN="(1024*1024)" -o x x.c y.c strlcpy.c ; ./x
NONE:825671 us
M
Thanks for the results on your machines Dave, Luke, and Tom. Interesting.
On Mon, Oct 02, 2006 at 02:30:11PM -0400, Tom Lane wrote:
> It appears that these results are a bit platform-dependent; on my x86_64
> (Xeon) Fedora 5 box, I get
*nod*
> Anyway, I looked at glibc's strncpy and determined t
Mark,
On 9/29/06 2:59 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Here are results over 64 Mbytes of memory, to ensure that every call is
> a cache miss:
On my Mac OSX intel laptop (Core Duo, 2.16 GHz, 2GB RAM, gcc 4.01):
Luke-Lonergans-Computer:~/strNcpy-perf-test lukelonergan$ gcc -O
[EMAIL PROTECTED] writes:
> Here is the cache hit case including your strlen+memcpy as 'LENCPY':
> $ gcc -O3 -std=c99 -DSTRING='"This is a very long sentence that is expected
> to be very slow."' -DN=1 -o x x.c y.c strlcpy.c ; ./x
> NONE:696157 us
> MEMCPY: 825118 us
> STRNCPY:79
Fri 9/29/2006 2:59 PM
To: Tom Lane
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Faster StrNCpy
On Fri, Sep 29, 2006 at 05:34:30PM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > If anybody is curious, here are my numbers for an AMD X2 3800+:
> You did not show you
On Fri, Sep 29, 2006 at 05:34:30PM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > If anybody is curious, here are my numbers for an AMD X2 3800+:
> You did not show your C code, so no one else can reproduce the test on
> other hardware. However, it looks like your compiler has unrolled the
[EMAIL PROTECTED] writes:
> If anybody is curious, here are my numbers for an AMD X2 3800+:
You did not show your C code, so no one else can reproduce the test on
other hardware. However, it looks like your compiler has unrolled the
memcpy into straight-line 8-byte moves, which makes it pretty ha
If anybody is curious, here are my numbers for an AMD X2 3800+:
$ gcc -O3 -std=c99 -DSTRING='"This is a very long sentence that is expected to
be slow."' -o x x.c y.c strlcpy.c ; ./x
NONE:620268 us
MEMCPY: 683135 us
STRNCPY:7952930 us
STRLCPY: 10042364 us
$ gcc -O3 -std=c99 -D
On Fri, Sep 29, 2006 at 11:21:21AM +0200, Markus Schaber wrote:
> Tom Lane wrote:
> >> Just wondering - are any of these cases where a memcpy() would work
> >> just as well? Or are you not sure that the source string is at least
> >> 64 bytes in length?
> >
> > In most cases, we're pretty sure tha
Markus Schaber <[EMAIL PROTECTED]> writes:
> There's another disadvantage of always copying 64 bytes:
> It may be that the 64-byte range crosses a page boundary. Now guess what
> happens when this next page is not mapped -> segfault.
Irrelevant, because in all interesting cases the Name field is p
Hi, Tom,
Tom Lane wrote:
> "Strong, David" <[EMAIL PROTECTED]> writes:
>> Just wondering - are any of these cases where a memcpy() would work
>> just as well? Or are you not sure that the source string is at least
>> 64 bytes in length?
>
> In most cases, we're pretty sure that it's *not* --- it'
"Strong, David" <[EMAIL PROTECTED]> writes:
> Just wondering - are any of these cases where a memcpy() would work
> just as well? Or are you not sure that the source string is at least
> 64 bytes in length?
In most cases, we're pretty sure that it's *not* --- it'll just be a
palloc'd C string.
I'
code that don't use memcpy () currently?
David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 27, 2006 4:27 PM
To: Strong, David
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Faster StrNCpy
On Wed, Sep 27, 2006 at 07:08:05AM
On Wed, Sep 27, 2006 at 07:08:05AM -0700, Strong, David wrote:
> We sometimes see TupleDescInitEntry () taking high CPU times via
> OProfile. This does include, amongst a lot of other code, a call to
> namestrcpy () which in turn calls StrNCpy (). Perhaps this is not a
> good candidate right now as
From: [EMAIL PROTECTED] on behalf of Tom Lane
Sent: Wed 9/27/2006 6:49 AM
To: Andrew Dunstan
Cc: josh@agliodbs.com; pgsql-hackers@postgresql.org; Neil Conway; Martijn van
Oosterhout
Subject: Re: [HACKERS] Faster StrNCpy
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom L
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What I'd like to do immediately is put in strlcpy() and hit the two or
>> three places I think are performance-relevant.
> What are the other hotspots?
The ones I can think of offhand are set_ps_display and use of strncpy as
a HashCo
Tom Lane wrote:
Josh Berkus writes:
What I'd like to do immediately is put in strlcpy() and hit the two or
three places I think are performance-relevant.
Immediately? Presumably you mean for 8.3?
No, I mean now. This is a performance bug and it's still open season on
bu
y; Martijn van Oosterhout
Subject: Re: [HACKERS] Faster StrNCpy
Josh Berkus writes:
>> What I'd like to do immediately is put in strlcpy() and hit the two or
>> three places I think are performance-relevant.
> Immediately? Presumably you mean for 8.3?
No, I mean now. This
Josh Berkus writes:
>> What I'd like to do immediately is put in strlcpy() and hit the two or
>> three places I think are performance-relevant.
> Immediately? Presumably you mean for 8.3?
No, I mean now. This is a performance bug and it's still open season on
bugs. If we were close to having
Tom,
> What I'd like to do immediately is put in strlcpy() and hit the two or
> three places I think are performance-relevant. I agree with trying to
> get rid of StrNCpy/strncpy calls over the long run, but it's just code
> beautification and probably not appropriate for beta.
Immediately? Pre
Neil Conway <[EMAIL PROTECTED]> writes:
> A wholesale replacement of strncpy() calls is probably worth doing --
> replacing them with strlcpy() if the source string is NUL-terminated,
> and I suppose memcpy() otherwise.
What I'd like to do immediately is put in strlcpy() and hit the two or
three p
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> You'll notice that it iterates once per char. Between that and the
> strlen() call in Tom's version, not sure which is the lesser evil.
Yeah, I was wondering that too. My code would require two scans of the
source string (one inside strlen and one in
On Tue, 2006-09-26 at 16:53 -0400, Tom Lane wrote:
> strlcpy does more than we need (note that none of the existing uses care
> about counting the overflowed bytes). Not sure if it's worth adopting
> those semantics when they're not really standard, but if you think a lot
> of people would be fami
Martijn van Oosterhout writes:
> I think that's why strlcpy was invented, to deal with the issues with
> strncpy.
> http://www.gratisoft.us/todd/papers/strlcpy.html
strlcpy does more than we need (note that none of the existing uses care
about counting the overflowed bytes). Not sure if it's wor
Martijn van Oosterhout wrote:
> On Tue, Sep 26, 2006 at 04:24:51PM -0400, Tom Lane wrote:
> > David Strong points out here
> > http://archives.postgresql.org/pgsql-hackers/2006-09/msg02071.php
> > that some popular implementations of strncpy(dst,src,n) are quite
> > inefficient when strlen(src) is
On Tue, Sep 26, 2006 at 04:24:51PM -0400, Tom Lane wrote:
> David Strong points out here
> http://archives.postgresql.org/pgsql-hackers/2006-09/msg02071.php
> that some popular implementations of strncpy(dst,src,n) are quite
> inefficient when strlen(src) is much less than n, because they don't
> o
David Strong points out here
http://archives.postgresql.org/pgsql-hackers/2006-09/msg02071.php
that some popular implementations of strncpy(dst,src,n) are quite
inefficient when strlen(src) is much less than n, because they don't
optimize the zero-pad step that is required by the standard.
It look
44 matches
Mail list logo
