This is the mail archive of the mailing list for the glibc 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]

[RFC]: strcat/strncat

Now my strlen starts to look complete so I can return back 
to strcat/strncat question.

There is dependency of strcat implementation on different strlen
implementations. I proposed in october to used a simple generic 

My main reason is that I did not found a binary that stress strcat 
enough so using strlen/strcpy would be faster thanks to better cache 

I did profiling with results below, part strcat.

Important part there is 'delays between calls' graph. It shows that
calls are not clustered so it will not stay in instruction cache.

These data are caused by 58% from vim. If I do not take vim into account
then delay curve stays same, 
destinations(number of calls graphs) have same distribution as strchr,
in source sizes (needle graph) there are almost no sources bigger than 8

Also strlen is called 650 times more and strcpy 100 times more than
For strcpy part there is possible optimization to split headers into
two variants where one has additional argument that it returns. This
allows us to jump to that variant.

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