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

Get rid of some quadratic behavior #842

Merged
merged 1 commit into from
Aug 20, 2024

Conversation

umanwizard
Copy link
Contributor

@umanwizard umanwizard commented Aug 19, 2024

markdown-match-bold and markdown-match-italic both call markdown-inline-code-at-pos-p on each candidate match, which takes linear time in the distance
from the start of the block to the point being checked.

In a large block with many candidate matches inside inline blocks, this is slow because the function is called with each candidate, resulting in overall quadratic behavior, which this commit fixes by starting the code-at-pos scan after the last already-found match.

For example, the following benchmark code:

(with-temp-buffer
  (dotimes (_ 400)
    (insert "`my_test_string`\n"))
  (markdown-mode)
  (car (benchmark-run
           (font-lock-debug-fontify))))

takes about 10.5 seconds before this commit, and about 0.14 seconds after this commit.

Description

Related Issue

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • Improvement (non-breaking change which improves an existing feature)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist

  • I have read the CONTRIBUTING.md document.
  • I have updated the documentation in the README.md file if necessary.
  • I have added an entry to CHANGES.md.
  • I have added tests to cover my changes.
  • All new and existing tests passed (using make test).
    (except test-markdown-export/buffer-local-css-path which was already failing)

markdown-match-bold and markdown-match-italic both call
markdown-inline-code-at-pos-p on each candidate match,
which takes linear time in the distance
from the start of the block to the point being checked.

In a large block with many candidate matches inside inline blocks,
this is slow because the function is called with each candidate, resulting in
overall quadratic behavior, which this commit fixes by starting the
code-at-pos scan after the last already-found match.

For example, the following benchmark code:

(with-temp-buffer
  (dotimes (_ 400)
    (insert "`my_test_string`\n"))
  (markdown-mode)
  (car (benchmark-run
           (font-lock-debug-fontify))))

takes about 10.5 seconds before this commit, and about 0.14 seconds after
this commit.
@umanwizard
Copy link
Contributor Author

umanwizard commented Aug 19, 2024

This fixes at least some of the issues contributing to #799 and #391, although I think there is more slow behavior lurking, so I won't claim those issues are entirely fixed.

@syohex syohex merged commit 6d1f08b into jrblevin:master Aug 20, 2024
4 checks passed
@hmelman
Copy link
Contributor

hmelman commented Aug 30, 2024

Thanks, this does fix a lot of #391 for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants