-
Notifications
You must be signed in to change notification settings - Fork 31.8k
[perf] Investigate TerminalLinkDetector#_parseWords
performance
#169867
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
Comments
Struggling a bit with a repro. I managed to repro it with some pretty unrealistic circumstances: The above was made by adding this setting:
Then mousing over this (cat long file and zoom out the workbench): I'll optimize against this and hope it goes away in telemetry. |
Verifying these perf-issues is really hard - automatic stack trace profiling has more in common with error telemetry than traditional bugs. @Tyriar Tho, having said that I did look into the code and do I believe looping over a string to find word-gap characters isn't the fastest option. I didn't measure and it is counter intuitive but I am very certain the using a |
@jrieken TIL you could split using a regex 🤯. It was quite fast based on my testing when I did the PR, the reason I didn't try a regex approach as regex escaping a user-defined string seems error prone. |
|
Handy, will reopen for next milestone |
re #170954
Automatic renderer profiling points towards _parseWords as being a cause for freezes. For 1.75.0-insiders we are seeing ~50 reports where this function was running for 350-500ms
This is a trace from todays insiders
The text was updated successfully, but these errors were encountered: