RE: [PATCH] Improve performance of strcat

["Wilco Dijkstra" <wdijkstr at arm dot com>]

> Ondřej Bílka wrote: 
> Also trying to benchmark C implementations is mostly meaningless, if you
> want good performance you need write at least assembly implementation of memcpy,
> strlen and strcpy. Optimizing one of these has bigger performance impact
> than rest of functions combined and if you do not care about that you do
> not have to care about this c implementation as well.

The issue is that you're forced to write lots of highly optimized assembly 
code in order to get good string performance for any new architecture.

This issue exists across GLIBC, for example the math functions used to be
extremely inefficient due to a bad generic implementation. With a simple
architecture independent patch I achieved 99% of the performance of the  
best optimized implementation. Rather than forcing all targets to add
large amounts of highly optimized assembler, why not put a little more 
effort into GLIBC generic code to ensure it is efficient to start with?

So the goal here is to provide good string performance using just C routines
and ensure they benefit further from assembler implementations of strlen, 
memcpy, memset etc.

> Also in case of strcat its easy to see that no matter how well you
> optimize it you cannot get faster than strcpy (dest+strlen (dest), src);
> minus constant overhead of like one function call.

Exactly, there is no need for a specialized assembler variant for strcat.

Wilco