[Python-Dev] memcmp performance

Stefan Behnel stefan_ml at behnel.de
Mon Oct 24 09:20:50 CEST 2011


"Martin v. Löwis", 23.10.2011 23:44:
>> I am still rooting for -fno-builtin-memcmp in both Python 2.7 and 3.3 ...
>> (after we put memcmp in unicode_compare)
>
> -1. We shouldn't do anything about this. Python has the tradition of not
> working around platform bugs, except if the work-arounds are necessary
> to make something work at all - i.e. in particular not for performance
> issues.
>
> If this is a serious problem, then platform vendors need to look into
> it (CPU vendor, compiler vendor, OS vendor). If they don't act, it's
> probably not a serious problem.
>
> In the specific case, I don't think it's a problem at all. It's not
> that memcmp is slow with the builtin version - it's just not as fast
> as it could be. Adding a compiler option would put a maintenance burden
> on Python - we already have way too many compiler options in
> configure.in, and there is no good procedure to ever take them out
> should they not be needed anymore.

I agree. Given that the analysis shows that the libc memcmp() is 
particularly fast on many Linux systems, it should be up to the Python 
package maintainers for these systems to set that option externally through 
the optimisation CFLAGS.

Stefan



More information about the Python-Dev mailing list