[issue13279] Add memcmp into unicode_compare for optimizing comparisons

[Antoine Pitrou]

Antoine Pitrou <pitrou at free.fr> added the comment:

> > Note we only really see the effect if we make sure that gcc
> > isn't emitting its "special" memcmp: that's why the -fno-builtin-memcmp
> > is SO important on gcc builds!
> 
> I'd rather infer the opposite: given how GCC generates code, this patch
> is not worthwhile. Given that it actually slows down Python in the
> default system configuration, I'm -1 on applying it. This is really not
> a route we should take; it leads to maintenance pain.

I agree with Martin. This patch would be very nice if there wasn't the
memcmp() perf problem. A possible solution would be to write a simple
optimized memcmp()-alike for our own purposes.
But I'm not sure it's really worth the hassle: comparing long unicode
strings doesn't strike me as a very common operation. Finding a short
substring, conatenating strings together, are all much more common.

----------
title: Add memcmp into unicode_compare for optimizing	comparisons -> Add memcmp into unicode_compare for optimizing comparisons

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13279>
_______________________________________