This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients RichIsMyName, asmodai, ezio.melotti, loewis, petri.lehtinen, pitrou, rhettinger, scoder, vstinner
Date 2011-10-31.23:47:43
SpamBayes Score 1.9312132e-07
Marked as misclassified No
Message-id <1320104603.3382.14.camel@localhost.localdomain>
In-reply-to <4EAF09D5.90800@v.loewis.de>
Content
> > 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.
History
Date User Action Args
2011-10-31 23:47:44pitrousetrecipients: + pitrou, loewis, rhettinger, scoder, vstinner, asmodai, ezio.melotti, petri.lehtinen, RichIsMyName
2011-10-31 23:47:43pitroulinkissue13279 messages
2011-10-31 23:47:43pitroucreate