> In generally, checking for a terminating character while copying is
> not efficient:
true, that's why I chose to use strlen, then memcpy.
> The code is short, but the jump instruction hurts caching and slows
> things down.
does branch prediction affect that at all?
> If you can copy most of the string as longwords, you gain a lot.
that's the point of the memcpy
> The new glibc "knows" about this stuff. Also the kernel code "knows"
> about this stuff.
glibc does all byte operations, doesn't it?
> There is no way at all that the macro first presented in this thread
> could ever be faster than the glibc code.
Please verify this with some kind of statistics. All my math and all my
bench marks tell me that I'm doing less instructions, and that it runs at
least 2 times as fast, even on very long strings.
> Further, the macro fails to copy the terminating null.
Yes, I'm sorry. It should have been strlen(b)+1, not strlen(b).
> In addition, the macro will not expand properly in some of the code
> where strcpy() is used, because of the lack of parenthesis. Also
> memcpy() returns a void pointer, strcpy() returns a char pointer so
> string operations that attempt to index the return value will fail.
I thought that typecasting the return from memcpy() to (char *) was
"ok".
My point was simply that it's faster to do a strlen() and a memcpy() (on
an intel pentium) then it is to copy the string byte by byte while
checking for null inside the loop.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu