A lot of code is duplicated in unicodeobject.c to manipulate ("encode/decode") surrogates. Each function has from one to three different implementations. The new decode_ucs4() function adds a new implementation. Attached patch replaces this code by macros.

I think that only the implementations of IS_HIGH_SURROGATE and IS_LOW_SURROGATE are important for speed. ((ch & 0xFFFFFC00UL) == 0xD800) (from decode_ucs4) is *a little bit* faster than (0xD800 <= ch && ch <= 0xDBFF) on my CPU (Atom Z520 @ 1.3 GHz): running test_unicode 4 times takes ~54 sec instead of ~57 sec (-3%).

These 3 macros have to be checked, I wrote the first one:

#define IS_SURROGATE(ch) (((ch) & 0xFFFFF800UL) == 0xD800)
#define IS_HIGH_SURROGATE(ch) (((ch) & 0xFFFFFC00UL) == 0xD800)
#define IS_LOW_SURROGATE(ch) (((ch) & 0xFFFFFC00UL) == 0xDC00)

I added cast to Py_UCS4 in COMBINE_SURROGATES to avoid integer overflow if Py_UNICODE is 16 bits (narrow build). It's maybe useless.

#define COMBINE_SURROGATES(ch1, ch2) \
 (((((Py_UCS4)(ch1) & 0x3FF) << 10) | ((Py_UCS4)(ch2) & 0x3FF)) + 0x10000)

HIGH_SURROGATE and LOW_SURROGATE require that their ordinal argument has been preproceed to fit in [0; 0xFFFF]. I added this requirement in the comment of these macros. It would be better to have only one macro to do the two operations, but because "*p++" (dereference and increment) is usually used, I prefer to avoid one unique macro (I don't like passing *p++ in a macro using its argument more than once).

Or we may add a third macro using HIGH_SURROGATE and LOW_SURROGATE.

I rewrote the main loop of PyUnicode_EncodeUTF16() to avoid an useless test on ch2 on narrow build.

I also added a IS_NONBMP macro just because I prefer macro over hardcoded constants.

We may use the following unlikely macro for IS_SURROGATE, IS_HIGH_SURROGATE and IS_LOW_SURROGATE:

#define likely(x)	__builtin_expect(!!(x), 1)
#define unlikely(x)	__builtin_expect(!!(x), 0)

I suppose that we should use microbenchmarks to validate these macros?

Should I open a new issue for this idea?

This has been proposed already in #10542 (the issue also has patches).

> HIGH_SURROGATE and LOW_SURROGATE require that their ordinal argument
> has been preproceed to fit in [0; 0xFFFF]. I added this requirement in
> the comment of these macros.

The macros should preprocess the argument themselves. It will make the
code even simpler.
Otherwise +1.

> This has been proposed already in #10542 (the issue also has patches).

The two issues are different: this issue is only a refactoring, whereas #10542 adds a new "feature" (function/macro: Py_UNICODE_NEXT).

#10542 proposes the following macros to factor out common code:
 #define _Py_UNICODE_ISSURROGATE
 #define _Py_UNICODE_ISHIGHSURROGATE
 #define _Py_UNICODE_ISLOWSURROGATE
 #define _Py_UNICODE_JOIN_SURROGATES
and to avoid checking for narrow/wide builds and recombine surrogates manually (so still refactoring):
 #define _Py_UNICODE_NEXT
 #define _Py_UNICODE_PUT_NEXT

Your patch proposes the same 4 macros:
 #define IS_SURROGATE
 #define IS_HIGH_SURROGATE
 #define IS_LOW_SURROGATE
 #define COMBINE_SURROGATES
+ 3 additional macros:
 #define IS_NONBMP
 #define HIGH_SURROGATE
 #define LOW_SURROGATE

So the two issue looks quite similar to me.

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti@gmail.com> added the comment:
> 
> #10542 proposes the following macros to factor out common code:
>  #define _Py_UNICODE_ISSURROGATE
>  #define _Py_UNICODE_ISHIGHSURROGATE
>  #define _Py_UNICODE_ISLOWSURROGATE
>  #define _Py_UNICODE_JOIN_SURROGATES
> and to avoid checking for narrow/wide builds and recombine surrogates manually (so still refactoring):
>  #define _Py_UNICODE_NEXT
>  #define _Py_UNICODE_PUT_NEXT
> 
> Your patch proposes the same 4 macros:
>  #define IS_SURROGATE
>  #define IS_HIGH_SURROGATE
>  #define IS_LOW_SURROGATE
>  #define COMBINE_SURROGATES
> + 3 additional macros:
>  #define IS_NONBMP
>  #define HIGH_SURROGATE
>  #define LOW_SURROGATE
> 
> So the two issue looks quite similar to me.

Can we please fold this issue into #10542. We've already had the
discussion there.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________
2011-10-04: PyCon DE 2011, Leipzig, Germany                49 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/