| msg82683 - (view) |
Author: Collin Winter (collinwinter) *  |
Date: 2009-02-24 22:54 |
| The attached patch adds a --with-py3k-warnings option to configure. Passing --without-py3k-warnings disables all Py3k compatibility warnings (the default is to keep the warnings). For production deployments where performance is more important than warnings no-one will see, this can provide a useful performance improvement: 2to3 (translate 2to3's source tree five times): Min: 22.406 -> 22.114: 1.32% faster Avg: 22.439 -> 22.158: 1.27% faster Django (render a 150x150 table 100 times): Min: 0.595 -> 0.586: 1.58% faster Avg: 0.598 -> 0.588: 1.76% faster Spitfire (render a 1000x1000 table 100 times): Min: 0.752 -> 0.743: 1.29% faster Avg: 0.754 -> 0.745: 1.25% faster Unpickle (unpickling a list of 8000 dicts 100 times): Min: 0.305 -> 0.301: 1.41% faster Avg: 0.307 -> 0.302: 1.49% faster Build env: gcc 4.3.1 x86_64 on Linux 2.6.18 (Core2 Duo) |
|
|
| msg82685 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-02-24 23:29 |
| I would like to understand the problem better first. I find it hard to believe that mere access to a global (even if frequent) costs so much. I think we should strive to make the warnings check faster if it indeed produces significant runtime costs, rather than offering to remove it. |
|
|
| msg82693 - (view) |
Author: Jeffrey Yasskin (jyasskin) * |
Date: 2009-02-25 02:12 |
| s/Leaving/Turning/ in configure.in. It looks like the convention for other --with flags that default to enabled is to document them as --with(out)-xxx. (except tsc...) I guess it's probably even better just to say what the default is in the documentation. "Trade away speed for Py3k compat warnings" is a bit harsh for a 1.5% penalty. How about "Define to get Py3k compatibility warnings at the cost of a little speed"? |
|
|
| msg82737 - (view) |
Author: Collin Winter (collinwinter) * |
Date: 2009-02-26 01:16 |
| Jeffrey: updated the patch to address your concerns. Martin: I'm not sure I completely understand it either, though it seems similar to . In the course of developing this patch, I tried also #ifdef'ing out all usages of the Py_Py3kWarningFlag global. This actually made things slower by around 5% across all the benchmarks I tested. Could be pipeline stalls or a code size issue, I really don't know. I'm not 100% convinced that something like this should go into CPython, as a different compiler/hardware combination could well render it moot. I mostly wanted a record of it, in case those few Python deployments with homogeneous compilers/hardware across their machines that might care about 1% better performance are interested. |
|
|
| msg82738 - (view) |
Author: Collin Winter (collinwinter) * |
Date: 2009-02-26 01:19 |
| Bah, forgot to run autoreconf. Fixed. |
|
|
| msg98465 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-01-28 15:39 |
| Given the very small benefits, I don't think there's any point in making this a configuration variable. A hardcoded flag would be sufficient, and expert users would be able to recompile their Python (as with the FAST_LOOPS flag). |
|
|
| msg98466 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-01-28 17:12 |
| I'm with Antoine on this one. Also, instead of removing the flag completely which will cause problems with extensions relying on it, I'd suggest to just disable the PyErr_WarnPy3k(msg, stacklevel) macro and turn it into a no-op if a compile time variable DISABLE_PY3K_WARNINGS (or similar) is defined (which should be undefined per default). |
|
|
| msg111829 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2010-07-28 16:13 |
| Both and agree that this should not be a configuration variable. I think a new patch is needed which follows the suggested solutions from the two messages given. |
|
|
| msg115337 - (view) |
Author: Daniel Stutzbach (stutzbach) |
Date: 2010-09-01 21:49 |
| Since this issue doesn't apply in Python 3 and (as I understand it) the 2.7 branch is only open to bug fixes, can we close this performance issue? |
|
|