better-cpp-syntax
better-cpp-syntax copied to clipboard
jeff-hykin
VSCode hangs with long parenthesis
Checklist
- [x] This problem exists even with the setting
"C_Cpp.enhancedColorization": "Disabled" - [ ] This bug exists for C
- [x] This bug exists for C++
- [ ] This bug exists for Objective-C
- [ ] This bug exists for Objective-C++
The code with a problem is:
https://gist.github.com/maroc81/f80bcecbd12e3b9a0496d18b970e880e
Seems #415 is back in a recent (few weeks or more) update to the "Better C++ Syntax" extension (currently running version 1.14.24). It's the same problem were a long line with a lot of space (even empty space) between parenthesis causes VS code to hang.
So I believe this isn't specific to C++
Spent a few hours debugging this today and it's not looking good. I tested if any one pattern or group of patterns was slowing it down and there doesn't appear to be. Commenting out everything and then commenting in different combinations of basic features (keywords, struct/enum blocks, comments) also still slows it down.
The following code will slowdown Javascript, Java, Typescript, CoffeeScript
DEFINE_SOMETHING(( a = 10, b = 200, d = 453094, f = 53, adlkfjad = a094-5, aodifj- = 359u30, aa = 3598, c = 20 43 ));
Interestingly enough, that code does not seem to slow down ruby or python at all, although they are more simple languages.
I'll have to investigate this more on a different day
Ah, I see what you mean. Javascript seems to be worse than Java but both exhibit incredibly poor performance.
Is this a VSCode bug? Should I create an issue there?
@jeff-hykin
perf clearly shows that the slowness is caused by line 598 (on master)
total time: 918.2317349999212ms
match failure
pattern name average time total time peak time
source.cpp:598 65.355755 457.490 457.459
source.cpp:15977 10.163977 50.820 50.812
...
This is likely because inline_builtin_storage_type has a bunch of sub-patterns that start with std_space, and the amount of spaces is so large that the regex engine cannot cache the std_space match, so it ends up matching multiple times.
Though it seems that more recent versions of oniguruma have improved on this, as performing the same regex comparison in ruby (2.6.4p104) takes only 0.29s (according to time (1)) on my machine
This is likely because
inline_builtin_storage_typehas a bunch of sub-patterns
I thought so too, but I already cleaned that up on cpp/fix/#462 and there is still bad performance
I also tried changing std_space to basically just be /\s*+/ and I was surprised to find minimal impact
Ok, so you are talking about the difference between total time and the sum of the total time for each type of match?
With fix/cpp/#462, regex testing accounts for ~190ms of the 712ms of total time. With a fix for the failing tests, it should be suitable to merge.
Sorry I thought I responded to this. Yeah I just mean total time. To a user it still feels slow, but the fix/cpp/#462 should be an improvement so I'll merge it
Hi Jeff. I came to report a hang issue, but suspect it would be a dupe of this. If I click to close the file, I can usually recover use of VS Code after about 10-15 seconds. The issue repros with the Better C++ Syntax extension (1.14.29) installed/enabled, but does not repro with it disabled. If needed for investigation, the file is here.
Is there a way to disable syntax highlighting for specific files since this is still a problem? There are only a handful of files that trigger this problem but I have to resort to other editors to look at them. It would be nice to permanently disable highlighting for the problem files. I can manually set the file as "Plain Text" but that setting is temporary.
I thought VS Code had made some fail-safes that reduced this significantly but maybe not.
We've talked about having an alternate minimal syntax, or trying to add a character cap for the handful of patterns that cause this kind of slowdown. But it is probably going to be a while before those are implemented.
A more immediate fix is to install a decently old version of the syntax before we added the advanced pattern. And an even more immediate fix is to change the settings to ignore syntax highlighting for lines longer than a certain limit, and just set the limit to be whatever it is in the files for your project