This is the mail archive of the
mailing list for the glibc project.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: libc-alpha at sourceware dot org
- Date: Mon, 28 Jan 2013 21:24:19 +0100
- Subject: [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.