Use memcpy() instead of for() loops in _PyUnicode_To*

[petdance]

BPO	39588
Nosy	@rhettinger, @vstinner, @ezio-melotti, @petdance

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2020-02-08.21:54:27.124>
created_at = <Date 2020-02-08.21:45:29.965>
labels = ['expert-unicode', 'performance']
title = 'Use memcpy() instead of for() loops in _PyUnicode_To*'
updated_at = <Date 2020-02-09.01:52:36.212>
user = 'https://github.com/petdance'

bugs.python.org fields:

activity = <Date 2020-02-09.01:52:36.212>
actor = 'petdance'
assignee = 'none'
closed = True
closed_date = <Date 2020-02-08.21:54:27.124>
closer = 'rhettinger'
components = ['Unicode']
creation = <Date 2020-02-08.21:45:29.965>
creator = 'petdance'
dependencies = []
files = []
hgrepos = []
issue_num = 39588
keywords = []
message_count = 3.0
messages = ['361636', '361638', '361640']
nosy_count = 4.0
nosy_names = ['rhettinger', 'vstinner', 'ezio.melotti', 'petdance']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'performance'
url = 'https://bugs.python.org/issue39588'
versions = []

[petdance]

Four functions in Objects/unicodectype.c copy values out of lookup tables with a for loop

        int i;
        for (i = 0; i < n; i++)
            res[i] = _PyUnicode_ExtendedCase[index + i];

instead of a memcpy

    memcpy(res, &_PyUnicode_ExtendedCase[index], n * sizeof(Py_UCS4));

My Apple clang version 11.0.0 on my Mac optimizes away the for loop and generates equivalent code to the memcpy.

gcc 4.8.5 on my Linux box (the newest GCC I have) does not optimize away the loop.

The four functions are:
_PyUnicode_ToLowerFull
_PyUnicode_ToTitleFull
_PyUnicode_ToUpperFull
_PyUnicode_ToFoldedFull

[rhettinger]

In the past, we've also gotten some gains by replacing memcpy() with for-loops. These kinds of optimization choices are best left to the compiler.

[petdance]

Thanks for replying. I figured that might be the case, which is why I made a ticket before bothering with a pull request.

I've also seen this kind of thing around:

                i = ctx->pattern[0];
                Py_ssize_t groupref = i+i;

instead of

                Py_ssize_t groupref = ctx->pattern[0]*2;

Is that also the kind of thing we would leave for the compiler to sort out?