This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Testing a speedup to libiberty/concat.c


 > From: Neil Booth <neil@daikokuya.co.uk>
 > 
 > Kaveh R. Ghazi wrote:-
 > 
 > > When glibc provides stpcpy, it seems like it's a big win to use it in
 > > lieu of a strlen/memcpy combo.  On x86-linux, this patch speeds up
 > > `concat' by 45%.
 > > 
 > > I'd like to get some testing on other systems.  On platforms whose
 > > libc doesn't provide stpcpy, this patch should have no effect.  If
 > > your libc does provide it, please apply the hunk to main, time it,
 > > then apply the other stuff and see what effect it has.  Adjust
 > > MAX_ITER so that it runs in about 20-30 seconds for a good test.
 > > (Careful, you may run out of memory, but I felt it important to
 > > isolate `concat' from `free'.)
 > 
 > Why not put a stpcpy equivalent in libiberty if it's useful?
 > Neil.

I've already done that.  It's the same as strlen/memcpy combo, but
with the additional overhead of a function call.  I timed it and it
becomes around 10% slower to use the libiberty version as opposed to
inlining the same strlen/memcpy equivalent which is what is done now.

We only want to use stpcpy if it's provided by (g)libc.
Please read the comment in the patch.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]