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.

Sign up for GitHub

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

Jump to bottom

fix_refs is by far the slowest part of this #187

Closed
oprypin opened this issue Dec 5, 2020 · 0 comments · Fixed by #188
Closed

fix_refs is by far the slowest part of this #187

oprypin opened this issue Dec 5, 2020 · 0 comments · Fixed by #188
Labels
feature New feature or request

Comments

@oprypin
Copy link
Member

oprypin commented Dec 5, 2020

It's quite sad that I'm running into real slowness when trying to apply mkdocstrings.

Anyway, I ran some profiling on a site with a lot of doc objects, and found that over half of the time (of the whole site build) is spent in fix_refs. It's probably not a surprise that it's slow, but it's really that slow. So if anyone's looking to improve performance, look at this first.

image
@oprypin oprypin added the feature New feature or request label Dec 5, 2020
@oprypin oprypin mentioned this issue Dec 6, 2020
Merged
pawamoy pushed a commit that referenced this issue Dec 6, 2020
@oprypin
perf: Rework autorefs replacement to not re-parse the final HTML
22a9e4b 
Define a "transport representation" for autorefs:

    <span data-mkdocstrings-identifier="SomeIdentifier">SomeHTML</span>

First a native Markdown extension translates from the usual `[SomeMarkdown][SomeIdentifier]` to the above, and then the post-process replacement mechanism (which is kept in the same place as before) doesn't need to be so careful and complicated, it just indiscriminately replaces such exact strings.

This is a very big boost in performance and I think is more future-proof.

Other mkdocstrings handlers are also free to use this mechanism: define whatever syntax for autorefs that they need and then insert this exact HTML themselves, for the postprocessing to pick up later. It used to be possible to insert the square-brackets Markdown before, but that was very fragile.

Issue #187: #187
PR #188: #188
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Rework autorefs replacement to not re-parse the final HTML oprypin/mkdocstrings
1 participant
@oprypin