Re: g_strjoinv() is very slow
- From: David Odin <David Odin bigfoot com>
- To: Raja R Harinath <harinath cs umn edu>
- Subject: Re: g_strjoinv() is very slow
- Date: Sun, 24 Sep 2000 00:03:33 +0200
On Sat, Sep 23, 2000 at 04:53:46PM -0500, Raja R Harinath wrote:
> David Odin <David Odin bigfoot com> writes:
> > On Sat, Sep 23, 2000 at 08:17:01PM +0100, Joel Becker wrote:
> > > On Sat, Sep 23, 2000 at 06:51:48PM +0200, David Odin wrote:
> > > > On Sat, Sep 23, 2000 at 12:40:32PM -0400, Havoc Pennington wrote:
> > > > I also think the same optimisations could be done with g_strjoin() and
> > > > g_strconcat(). I'll have a look.
> > >
> > > Maybe I'm a pedant, but I suspect we should find out what other
> > > platforms perform like. I know that lots of them use inline ASM for
> > > these functions. Maybe a test case in configure to decide?
> > >
> > Here is my point:
> > To perform a strcat(), you have to first find the end of the first string,
> > and then copy the second one in that place. It will always be slower than
> > only perform the copy.
> > OK. In my algorithm, I use strlen(), but it is only used on the added
> > string, which is obviously shorter than the resulting one.
> Maybe this should be re-written to use stpcpy instead -- stpcpy
> returns the pointer to the end of the target after the copy.
> Of course, a portablility wrapper will be needed.
Actually, it is a very good idea, but I think isn't very portable on
I didn't know this function, and I saw this from the man page:
This function is not part of the ANSI or POSIX standards,
and is not customary on Unix systems, but is not a GNU
invention either. Perhaps it comes from MS-DOS.
Havoc, what do you think? Should I re-write my patch to use stpcpy() and
adding a test to configure.in?
David Odin bigfoot com
] [Thread Prev