Antoine Pitrou <pit...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue13279> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
