Recent ST3 builds seems to degrade in large C++ file loading performance and the majority of time is spent on the sregex matching functions. Are there plans to mitigate this? Try files like http://hg.mozilla.org/mozilla-central/file/ffac2798999c/layout/style/nsCSSParser.cpp
Large C++ file loading performance in recent ST3 betas
jfcherng
#2
I am using ST 3122 and didn’t feel any noticeable delay with the example you provide.
iirc, wbond used sqlite3.c, which has nearly 200k lines, as the test case while he was re-writing C/C++ syntax files.
It takes about 1~2 seconds to load sqlite3.c for me.
But there seems no C/C+±related changes after the latest beta, not sure why you experiencing that…
Or maybe more specifically speaking, you mean “loading” or “rendering”?
0 Likes
jjgod
#3
I mean loading, there is a significant delay when the loading progress bar is present. Maybe not recent but more like last few months. If there are links to previous builds on https://www.sublimetext.com/3dev I can certainly test and regress.
0 Likes
jfcherng
#4
We can simply modify the version number in the download link to get an old release.
0 Likes
wbond
#5
The first time you open a C++ file after installing a new build or installing a new syntax from Package Control, the syntax is compiled. This is necessary since syntax files can include other syntaxes. Additionally, changes to your syntaxes will trigger re-indexing of your project, which can affect the CPU resources available for opening a large file.
The file you linked takes 313ms to tokenize on my 2013 rMBP. You can run this on your machine by using the “Syntax Tests” build system with the file open. Run the “Performance” variant.
In general, C, C++, Objective-C and Objective-C++ tokenization should be significantly faster than in old builds since we exclusively use our customized regex engine.
1 Like
jps
#6
It’s worth checking that you are using the default C++ syntax definition, and not a third party one. The simplest way to verify if you’re on Windows is to download the Portable version and open the file in question with that.
0 Likes
jjgod
#7
Syntax “Packages/Objective-C/Objective-C++.sublime-syntax” took an average of 243.6ms over 10 runs
Sorry that I cannot provide my own source file as it’s proprietary software, I will see if I can recreate one with similar performance characteristics I have observed. But the performance I see is very abnormal: sometimes it’s perfectly fine, sometimes when I type parenthesis characters like [, ], {, }, (, ) they will take a lot of time to respond and you can see the OS X beachball for a few seconds (sometimes as long as 30 seconds). But after I restarted my ST3 it went fine for a while, until the situation happens again. I don’t know if there is anyway to diagnose that from my side.
0 Likes
jjgod
#8
Also, when it spins like that, I took a spin dump and the deepest stack is sregex functions, I will try to capture a new one and paste it.
0 Likes
jjgod
#11
Turns out it’s not as easy to regress as there is no portable version on Mac, and older versions don’t understand newer versions’ syntax format:
Error loading syntax file “Packages/Objective-C/Objective-C++.sublime-syntax”: Unable to open Packages/Objective-C/Objective-C++.sublime-syntax
0 Likes
jjgod
#12
Managed to find the regression point after all. The loading time for my file is instant all the way until build 3109 (don’t even see the progress bar), but since 3110 it became much slower.
0 Likes
jjgod
#13
I can reproduce the same case with the nsCSSParser.cpp file linked above, 3109: instant, 3110: much slower.
0 Likes
wbond
#14
The C family of syntaxes was largely rewritten in build 3010. Since you mentioned (, [, {, could you try typing one of those in a place that causes a hang and then run the Performance build variant?
I am wondering if having an unclosed pair of punctuation is causing the tokenizer to have trouble parsing the rest of the file. If this is the case, you could probably notice that the highlighting seems off for chunks of the file.
0 Likes
jjgod
#15
I can. But when I test file loading I tested the unmodified files without unclosed pairs, and the performance differences are definitely very noticeable compare to build 3109. So pure unclosed pairs don’t explain that.
0 Likes
jjgod
#16
Also, the performance when editing [], {}, () seems to be fine when the files are initially loaded, but degrades after editing the file for a while.
0 Likes
wbond
#17
Are you using any third-party packages? You can move your data directory as mentioned in http://www.sublimetext.com/docs/3/revert.html to get a clean state on OS X.
0 Likes
jjgod
#19
After some uses, I got this when timing a file with unclosed {:
Syntax “Packages/Objective-C/Objective-C++.sublime-syntax” took an average of 9,015.4ms over 10 runs
0 Likes
jjgod
#20
Spindump with build tests: https://gist.github.com/jjgod/0e65b96ab698e87a1261e563e9b4aeab
0 Likes