Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build 60x slower with sphinx v3.2 compared to v2.4 when using autodoc_mock_imports #8350

Closed
ghost opened this issue Oct 29, 2020 · 2 comments

Comments

@ghost
Copy link

ghost commented Oct 29, 2020

[EDIT: updated with reproducible example]

Describe the bug

On a large python project, we recently updated our kernel to use a later version of Sphinx, and the build time increased from 44 seconds to over half an hour!

I believe the issue is related to the automodule mock imports: the slowdown only occurs when a mocked-out library is imported with the from ... import ... syntax as described below.

To Reproduce

Example module foo, and a mocked-out external dependency baz:

foo.py:

from baz import BazClass
import IPython

index.rst :

.. autosummary::
   :toctree: _autosummary
   
   foo

config.py:

autodoc_mock_imports = ["baz"]
autosummary_generate = True  
autosummary_generate_overwrite = True
extensions = ['sphinx.ext.autodoc',  'sphinx.ext.autosummary']

Build command:

$ sphinx-build docs docs/html -E -a

This leads to quite a slow build time of ~2 minutes, whereas it ought to build in about 5 seconds.

Environment info

  • OS: Linux-3.10
  • Python version: 3.8.5
  • Sphinx version: 3.2.1
  • Sphinx extensions: autodoc, autosummary, napoleon

Additional context

Bizarrely, any of these changes speeds up the build time to 5 seconds:

  • Writing import baz.BazClass rather than from baz import BazClass in foo.py
  • Commenting out from baz import BazClass in foo.py
  • Commenting out import IPython in foo.py
  • Making an actual module called baz available on the path and removing it from the autodoc_mock_imports list

I don't know why the IPython import is needed for the bug to appear. I have ipython v7.18.1 . In practice, none of our modules import IPython directly, but it is imported indirectly in several common libraries like ipykernel and ipywidgets.

On my real-life project, the build time is over half an hour. We mock out a lot of dependencies in the build script assigning a list of modules to autodoc_mock_imports. The vast majority of the documentation is automatically built from the module docstrings with autosummary.

Possibly related: Issue #7479 was closed by #7504 , slowdown apparently due to "recursive calls to inspect.unwrap() for Mocked objects".

@ghost ghost added the type:bug label Oct 29, 2020
@ghost ghost changed the title Build 60x slower with sphinx v3.2.1 compared to v2.4.0, on large project Build 60x slower with sphinx v3.2 compared to v2.4 when using autodoc_mock_imports Oct 29, 2020
@ghost
Copy link
Author

ghost commented Nov 9, 2020

@tk0miya I wonder if this bug has a similar root cause to #8164 , which I believe you fixed?

@tk0miya tk0miya added this to the 3.3.1 milestone Nov 11, 2020
tk0miya added a commit to tk0miya/sphinx that referenced this issue Nov 11, 2020
The mock objects set up via `autosummary_mock_imports` causes slow down
of autosummary stub generation because AttributeDocumenter falls into
infinite recursion call to unwrap decorators of mocked objects.

To avoid the trouble, this blocks unwrapping decorators of mocked
objects.
@tk0miya
Copy link
Member

tk0miya commented Nov 11, 2020

Sorry for the late response. Finally, I found the reason for this slowdown. I think #8412 will fix your case. Please check it.

tk0miya added a commit that referenced this issue Nov 12, 2020
…auses_slowdown

Fix #8350: autosummary_mock_imports causes slow down builds
@tk0miya tk0miya closed this as completed Nov 12, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 18, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant