ST is indeed indexing with my Build 3124. It seems to be stuck on 7%. There’s one large section of my project which is the node_modules section of my Twitter Bootstrap sass installation ~ 147 MB with 20,000+ files. Anyway I can get it to ignore that?
Whilst it’s indexing it’s taking up 50% CPU and making other applications like Firefox sluggish.
Ah - this looks promising: [solved] 3124 is killing my cpu fan
"index_exclude_patterns": ["*.log", "node_modules/*", "bower_components/*"]
Have tried the index_exclude_patterns setting, but it still appears to be trying to index node_modules.
I’m getting the following in the console:
worker 9092 appears stuck while processing file /C/inetpub/wwwroot/xxx/app/webroot/bootstrap-3.3.6/node_modules/acorn-globals/README.md, killing process
worker 5388 appears stuck while processing file /C/inetpub/wwwroot/xxx/app/webroot/bootstrap-3.3.6/node_modules/argparse/node_modules/underscore.string/README.markdown, killing process
worker 9092 appears stuck while processing file /C/inetpub/wwwroot/xxx/app/webroot/bootstrap-3.3.6/node_modules/acorn-globals/README.md, killing process
Edit: Don’t know why it was stuck on those two files. But it looped over those two files trying to read them indefinitely.
so I added "*.md", "*.markdown" to the index_exclude_patterns. Ugly solution but has got me beyond 7%.
yep… open up the README.markdown freezes up ST completely
Edit: and my indexing was at 95%… 
Edit2: actually on opening ST again, indexing has stopped, i.e. it appears ok.
All is good, just as long as I don’t try opening the evil markdown file…
Edit3: this is what I get opening the README.md file. Obviously a problem with the MarkdownEditing package. I’ll go and raise a bug there.
Someone beat me to it: https://github.com/SublimeText-Markdown/MarkdownEditing/issues/390
How to see indexing progress? When I try to open a file with about 1k lines in a large project sublime just freezes. Pressing CMD+P and typing at least 1 character does the same. OSX El Capitan
For those who still experiences the same problem, downgrading to 3114 helps https://download.sublimetext.com/Sublime%20Text%20Build%203114.dmg
Most likely there is a package installed that is causing issues. What kind of file are you trying to open? I would look for a package related to that file type.
Please, how do I revert??? ST3 keeps crashing and I’m having all sorts of slow performance and package issues
Hearing this a lot lately. I think it would be worth having Sublime ignore node_modules by default as they can contain hundreds of thousands of files per project
Just go to the download page https://www.sublimetext.com/3, copy the download link, paste it to your browsers address bar and change the build number (I took build number 3114), voila! Run the install program, everything will be there as if nothing happened.
I’ve posted a sticky topic on this issue at [Solved] High CPU Usage in Beta 3124.
Reverting should (ideally) be a last resort. It doesn’t address the problem, and just means you’ll be stuck on an old version of the software without helping identify if there is a problem, or what the problem is.
Dev Build 3125 came out with a workaround for this last night.
Apparently none of the users of the dev builds were using the third-party package causing the issue. The issue does not exist on a vanilla install.
v.3126
No 3rd party package - unless Laravel 5.6 can be considered one
indexing cooks CPU when working with blades (Laravel templating file)
message:
worker 8004 appears stuck while processing file dir/messaging/center.blade.php, killing process
Setting “index_workers” to 1 - does not help much
Best to exclude blades from indexing using:
“index_exclude_patterns”: [".log", ".blade.php"]
Indexing engine seems to work without any hiccups with non-blade files.
Just my 2-cents.
yes… so probably it has a blade syntax definition which causes catastrophic backtracking.
why such an old ST build?
why such an old ST build
I had my share with ‘bad updates’ messing with my work.
I am not talking specifically about Sublime.
In general. Across different soft.
So I always hard-code disable auto-update capacity in /etc/hosts (I am on win), just to make sure, as not all soft allows, or in some cases even works according to own specs in that matter.
So I always let soft ‘mature’, before updating.
But you are right, it is time update.
