ENH: optimize STRING_compare by using memcmp #4572
Conversation
|
maybe because memcmp does not stop on null so short strings with long paddings are slower? |
|
oh wait this is wrong when comparing strings with garbage behind NULL edit: no the old function does also not stop, but its probably not worth thinking about what is fastest, should not be an important function |
|
@juliantaylor I don't remember ;) Some of the gcc library functions were inefficient and slow back in the day, |
|
turns out this is actually useful when using a void type to sort an array by byte values |
| @@ -2598,12 +2599,14 @@ STRING_compare(char *ip1, char *ip2, PyArrayObject *ap) | |||
| const unsigned char *c1 = (unsigned char *)ip1; | |||
| const unsigned char *c2 = (unsigned char *)ip2; | |||
| const size_t len = PyArray_DESCR(ap)->elsize; | |||
There was a problem hiding this comment.
Looks good to me, I think it is correct that we compare all bytes, since only trailing 0-bytes are stripped (as\x00d\x00\x00 is 'as\x00d). Probably doesn't matter, butelsize` actually is int I think
There was a problem hiding this comment.
Oh, heh, in my mind I combined the old and new usage of i, so nvm.
|
I guess this can go in, speeds up at least one usecase and is simple |
ENH: optimize STRING_compare by using memcmp
No description provided.