Fix quadratic rendering time for many inline links - #1621
Conversation
Scanning from index 0 after every inline-pattern match rescanned the unprocessed text repeatedly, making conversion quadratic in the number of inline elements. Return the index just past the inserted placeholder so the next scan starts at the unprocessed tail. Fixes Python-Markdown#1619.
|
Thanks for the detailed review. Commit b745bba addresses the points raised: it removes the wall-clock regression test, replaces it with a deterministic search-offset assertion, and moves #1619 under Unreleased > Changed to document the inline-processor behavior/API impact. The full unittest suite passes with 1,089 tests and 13 skipped; changed-file flake8 and git diff --check pass. |
|
Thank you for addressing my concerns. I am going to let @facelssuser review this as he has a better grasp of the affected code. |
|
Thanks, @waylan. I appreciate the follow-up; I’ll wait for @facelssuser’s review of the affected code. |
|
I will hopefully get to this sometime this week. I've become somewhat exhausted with the onslaught of everyone pointing AI at every project on the internet. I'm already dealing with similar issues on numerous projects I support. |
|
Understood. I will leave the draft unchanged while you assess it; no further follow-up is needed from me right now. |
|
Thanks for all of your your hard work, I know you all are busy. Let me know if I can assist. |
Description
Rendering a paragraph containing many inline links took quadratic time:
each match replaced the link with a placeholder and then rescanned the
whole remaining text from index 0, so N links cost O(N²) pattern work.
'[link](x)' * 8192took ~7s before this change and ~0.3s after.__applyPatternnow returns the index just past the inserted placeholderso the next scan starts at the unprocessed tail.
Fixes #1619.
AI Assistance Disclosure
Claude (via Command Code) assisted with implementation and testing; the change was fully reviewed and verified by a human.
Checklist