Re: g_strjoinv() is very slow

[David Odin <David Odin bigfoot com>]

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
non-GNU platforms. 

  I didn't know this function, and I saw this from the man page:
CONFORMING TO
       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?

         Regards,

                    DindinX

-- 
David Odin bigfoot com