Stefan Behnel <[email protected]> wrote: > FWIW, I think this definitely makes sense in cases where the C > implementation is essentially a complete replacement of the original > module, such as in this case. I even sometimes suggest compiling Python > modules with Cython if the import time matters. > > For "normal" accelerator modules that only replace a part of a Python > module with a native implementation, this is less likely to make a large > enough difference to make up for the additional complexity due to the code > split.
I wonder how big the cumulative effect is (yes, I should really measure instead of wondering ;)). Anyhow, to measure the effect for decimal in a real world application, these are the startup times of Python if decimal is imported at startup: diff --git a/Lib/site.py b/Lib/site.py --- a/Lib/site.py +++ b/Lib/site.py @@ -72,6 +72,7 @@ import os import builtins import _sitebuiltins +import decimal # Prefixes for site-packages; add additional prefixes like /usr/local here PREFIXES = [sys.prefix, sys.exec_prefix] With the current scheme: ======================== $ time ./python -c "pass" real 0m0.040s user 0m0.036s sys 0m0.004s With the patch for #19232: ========================== $ time ./python -c "pass" real 0m0.023s user 0m0.016s sys 0m0.004s But I agree that decimal.py is a special case, since it's very large *and* imports many other modules. Stefan Krah _______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com