More fast utf-8 decoding

[loewis]

http://bugs.python.org/review/14654/diff/4717/16756
File Objects/stringlib/codecs.h (right):

http://bugs.python.org/review/14654/diff/4717/16756#newcode51
Objects/stringlib/codecs.h:51: _p[0] = (STRINGLIB_CHAR)(value & 0xFFu);
-1 on this chunk. It assumes that the compiler is not smart enough to figure out
itself that it can read from value, and this doubles the number of lines just
because of a potential lack of optimization in the compiler.

http://bugs.python.org/review/14654/diff/4717/16756#newcode97
Objects/stringlib/codecs.h:97: if (ch < 0xE0) {
Those range checks all need comments.

[storchaka]

http://bugs.python.org/review/14654/diff/4717/16756
File Objects/stringlib/codecs.h (right):

http://bugs.python.org/review/14654/diff/4717/16756#newcode51
Objects/stringlib/codecs.h:51: _p[0] = (STRINGLIB_CHAR)(value & 0xFFu);
On 2012/04/24 14:36:45, loewis wrote:
> -1 on this chunk. It assumes that the compiler is not smart enough to figure
out
> itself that it can read from value, and this doubles the number of lines just
> because of a potential lack of optimization in the compiler.

It is affects performance. See issue14249. Actually it depends not only on the
compiler, but mainly from the CPU. I'm not sure that the compiler can optimize
here.

[loewis]

http://bugs.python.org/review/14654/diff/4717/16756
File Objects/stringlib/codecs.h (right):

http://bugs.python.org/review/14654/diff/4717/16756#newcode51
Objects/stringlib/codecs.h:51: _p[0] = (STRINGLIB_CHAR)(value & 0xFFu);
> It is affects performance.

That is not a sufficient reason alone to make a change. The change also needs to
be maintainable. This here is code bloat, for only a small gain.

> I'm not sure that the compiler can optimize here.

The compiler could very well determine that s[0], s[1], ... are already loaded
into "value", and fetch it from there instead of from the memory. So it could
generate exactly the same code that you have written manually.