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

Fix colorization speed in large files #1829

Merged
merged 8 commits into from Nov 24, 2016
Merged

Fix colorization speed in large files #1829

merged 8 commits into from Nov 24, 2016

Conversation

dsyme
Copy link
Contributor

@dsyme dsyme commented Nov 24, 2016

Fixes #1821

Incremental colorization was not being effective on changing files for a number of reasons

  • Data cache was keyed by source text rather than document ID
  • We were writing None entries right through to end-of-file even when we could stop earlier
  • We weren't checking that start-of-line indexes and lex states were still the same when reusing entries
  • Tokenizers getting recreated for each line - we can cache these as well.

I've tried the PR out on large files and it works much more efficiently.

Also a fix to make ShouldTriggerCompletionAux faster in the common case where not pressing .

@dsyme
Copy link
Contributor Author

dsyme commented Nov 24, 2016

This also fixes glyphs: #1806. Public/private/protected is not yet propagated to the glyph but this gives us feature parity with VS2015

capture2

@dsyme
Copy link
Contributor Author

dsyme commented Nov 24, 2016

@OmarTawfik I'm merging this since it's solid and fast when I've been using it, please review.

@dsyme dsyme merged commit bfe4086 into dotnet:master Nov 24, 2016
@OmarTawfik
Copy link
Contributor

@dsyme thanks for taking care of this!

nosami pushed a commit to xamarin/visualfsharp that referenced this pull request Jan 26, 2022
Fixes dotnet#1821

Incremental colorization was not being effective on changing files for a number of reasons
•Data cache was keyed by source text rather than document ID
•We were writing None entries right through to end-of-file even when we could stop earlier
•We weren't checking that start-of-line indexes and lex states were still the same when reusing entries
•Tokenizers getting recreated for each line - we can cache these as well.

I've tried the PR out on large files and it works much more efficiently.

Also a fix to make  ShouldTriggerCompletionAux  faster in the common case where not pressing  . 

This also fixes glyphs: dotnet#1806. Public/private/protected is not yet propagated to the glyph but this gives us feature parity with VS2015
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.

VS2017 RC - Colorization causing slow editing in large files
3 participants