[BUG] The `_distutils_hack` pth file causes significant startup slowdown

[pablogsal]

setuptools version

60.0.0

Python version

ALL

OS

ALL

Additional environment information

No response

Description

Since setuptools 60.0.0 has been released, Python startup has been impacted noticeably:

https://speed.python.org/timeline/#/?exe=12&ben=python_startup&env=1&revs=50&equid=off&quarts=on&extr=on

This is due to the new pth file that setuptools installs for injecting the distutils hack. The pth imports the _distutils_hack module and the ramifications of this import has a noticeable impact on startup time as you can see in the benchmark server.

Here is an estimation of the cost using -X importtime on my machine:

import time:       278 |        278 |         types
import time:       112 |        112 |           _operator
import time:       419 |        531 |         operator
import time:       129 |        129 |             itertools
import time:       325 |        325 |             keyword
import time:       468 |        468 |             reprlib
import time:       258 |        258 |             _collections
import time:       978 |       2156 |           collections
import time:        78 |         78 |           _functools
import time:       835 |       3068 |         functools
import time:      1359 |       5235 |       enum
import time:       138 |        138 |         _sre
import time:       497 |        497 |           sre_constants
import time:       528 |       1025 |         sre_parse
import time:       512 |       1674 |       sre_compile
import time:       109 |        109 |       _locale
import time:       886 |        886 |       copyreg
import time:       671 |       8574 |     re
import time:       471 |        471 |       warnings
import time:       330 |        801 |     importlib
import time:       906 |      10279 |   _distutils_hack

This almost doubles the startup time (from 13501 us to 24093 us) and unfortunately, as almost all Python installations will have the pth file installed by default, all Python installations will double its startup time.

We have been working very hard to reduce startup time with things like frozen modules (https://bugs.python.org/issue45020) and other optimizations and is unfortunate that this gains are being lost due to this.

See: https://bugs.python.org/issue46110 for more information and discussion

Expected behavior

The distutils hack doesn't impact startup time.

How to Reproduce

Measure the time spent in python -c pass. You can use python -Ximporttime -c pass to generate the import time table for convenience and debugging.

Output

Relevant output of python -X importtime -c pass:

...
import time:       278 |        278 |         types
import time:       112 |        112 |           _operator
import time:       419 |        531 |         operator
import time:       129 |        129 |             itertools
import time:       325 |        325 |             keyword
import time:       468 |        468 |             reprlib
import time:       258 |        258 |             _collections
import time:       978 |       2156 |           collections
import time:        78 |         78 |           _functools
import time:       835 |       3068 |         functools
import time:      1359 |       5235 |       enum
import time:       138 |        138 |         _sre
import time:       497 |        497 |           sre_constants
import time:       528 |       1025 |         sre_parse
import time:       512 |       1674 |       sre_compile
import time:       109 |        109 |       _locale
import time:       886 |        886 |       copyreg
import time:       671 |       8574 |     re
import time:       471 |        471 |       warnings
import time:       330 |        801 |     importlib
import time:       906 |      10279 |   _distutils_hack
...

Code of Conduct

• I agree to follow the PSF Code of Conduct

[pablogsal]

CC: @brandtbucher @ericsnowcurrently @lpereira @markshannon @iritkatriel

[jaraco]

Thanks for reporting. I was aware this was a risk.

I do believe the riskslowdown is justifiable, even at the reported level of 2x (11ms), given that:

• This hack is meant to be temporary. As soon as is achievable, Setuptools aims to deprecate the use of import distutils and obviate the need for the hack.
• Setuptools desires not to be installed at run time. It is now possible for most if not all environments to move away from having Setuptools installed except during builds. Many environments today can reclaim startup speed by uninstalling Setuptools (either early and relying on PIP_USE_PEP517 or after installing packages into the environment).
• This hack provides enormous value as an essential transition to a world without distutils in the stdlib. It's enabling the consolidation of the dozens of forks of distutils that exist as monkeypatches of the stdlib.
• The hack also provides a low-cost opt-out with SETUPTOOLS_USE_DISTUTILS=stdlib.

That said, there may be some performance optimizations that can be made, and probably should be made if they don't encumber the implementation too much.

[jaraco]

For importlib_metadata, I developed pytest-perf to exercise performance tests and prevent regressions. That could be employed here to (a) measure the performance and (b) prevent regressions as performance is improved.

[tiran]

You could reduce the impact on startup performance by not using contextlib and moving the import of re into the function body.

[gvanrossum]

In order to avoid importing re you would also have to remove the warnings.filterwarnings() call -- that function uses re. What does that call do anyway?

How temporary is the hack? Will it be gone by the time 3.11 final is released (coming October)?

[gvanrossum]

If you wanted to make us really happy, you could get rid of the filterwarnings call, and delay importing of warnings, re, importlib and contextlib. That avoids any imports in the default python -c pass case that aren't already frozen.

[gvanrossum]

In order to avoid importing re you would also have to remove the warnings.filterwarnings() call -- that function uses re. What does that call do anyway?

Answering my own question, this seems to get rid of the warning printed by importing distutils whenever _distutils_hack is imported. This could probably also be postponed, e.g. put this line in spec_for_distutils().

(@jaraco, would it be helpful if I submitted a PR?)