Sublime Forum

Why is Sublime using significant CPU when idle?

#5

OK, I’ve narrowed down the problem.

If I start Sublime Text clean – no files, folders, or projects open (i.e., I closed out of everything before shutting down), then:

  1. As long as I only open individual files – as long as I never open a project and never open a folder/directory – then the CPU hovers at around 0.2%.

  2. But as soon as I open a directory/folder or I open a folder, then Sublime Text shoots up to 6% CPU and stays there … even if I subsequently close all open files and close the project/directory window. I have to kill the application and re-open it (clean) to get back to 0% (or very close to 0%) CPU.

This behavior exists with or without the few packages I use installed.


Dave

0 Likes

#6

OK, as suggested earlier in this thread, this problem is a re-indexing issue on OS X. It seems to be unrelated to the type or quantity of files being indexed.

I don’t know what SublimeText3 is indexing, but it is indexing something over-and-over-and-over-again. Even if there are only a very few files in the project/directory-tree, the indexing occurs continuously and repeatedly. The only way to avoid this is to avoid opening a directory or project.

I’d really like to see this OS X issue resolved. :frowning:

Here’s a trace using ‘opensnoop’ on my Mac: These lines are output rapidly:

503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index/000062.sst 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index/000625.sst 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index/000062.sst 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index/000626.sst 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index/000062.sst 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index/000627.sst 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index/000062.sst 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index/000628.sst 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index/000062.sst 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index/000629.sst 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index q 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index/000062.sst 503 7819 Sublime Text 24 /Users/datihein/Library/Application Support/Sublime Text 3/Index/000630.sst


Dave Hein

0 Likes

#7

More info, and a workaround …

I looked in to the Index directory, as identified by opensnoop (see my previous post), and found a LOG file with these log entries (a new block of entries every second):

2013/08/29-06:52:24.942541 10f699000 Compacting 19@0 + 3@1 files 2013/08/29-06:52:26.742562 10f699000 compacted to: files 19 5 0 0 0 0 0 ] 2013/08/29-06:52:26.742723 10f699000 Delete type=2 #400 2013/08/29-06:52:26.743659 10f699000 Compaction error: IO error: /Users/datihein/Library/Application Support/Sublime Text 3/Index/000062.sst: Invalid argument 2013/08/29-06:52:26.743692 10f699000 Waiting after background compaction error: IO error: /Users/datihein/Library/Application Support/Sublime Text 3/Index/000062.sst: Invalid argument 2013/08/29-06:52:27.744794 10f699000 Compacting 19@0 + 3@1 files 2013/08/29-06:52:27.855327 10f699000 compacted to: files 19 5 0 0 0 0 0 ] 2013/08/29-06:52:27.855470 10f699000 Delete type=2 #401 2013/08/29-06:52:27.944136 10f699000 Compaction error: IO error: /Users/datihein/Library/Application Support/Sublime Text 3/Index/000062.sst: Invalid argument 2013/08/29-06:52:27.944185 10f699000 Waiting after background compaction error: IO error: /Users/datihein/Library/Application Support/Sublime Text 3/Index/000062.sst: Invalid argument

On a hunch, I shutdown ST3 and renamed the Index directory to Index.save and then created a new, emtpy, Index directory. Then I restarted ST3 and now it idles along at 0.2% CPU. Much better.

So there is some kind of defect in the code that isn’t handling an error condition properly, causing the indexing to restart after the error. Repeat ad naseum.

FYI, the file it complains about – 000062.sst – is a zero-length file, dated a few months ago.

Bottom line: there is a bug in error handling in the indexing, but you can workaround the bug by clearing out the Index directory if you notice ST3 consuming a lot of CPU when idle for a long time (many minutes).

2 Likes

#8

BIG thanks on that workaround! This was making my fan kick on and drive me insane.

0 Likes

#9

thanks for the workaround!!!

But we need a fix :s

0 Likes

#10

I’m having the exact same issue on windows 7 and build 3047 of ST3. Whenever I open a project, my cpu usage eventually jumps to 100% and stays there until I shut down ST3. This makes ST3 virtually unusable. This just started happening today. I’m on a trial account currently with ST3 and have plans to purchase the software but this makes me worried.

0 Likes

#11

I tried the above workaround but and it works for a bit but after about 1 hour my cpu load jumps back up to 100%. After I shutdown ST3 and then reopen it my CPU usage hits 50% and stays there until it finally jumps to 100%.

0 Likes

#12

The issue with zero length .sst files is an underlying one with leveldb, as far as I can tell. The dev builds (sublimetext.com/3dev) use a newer version of leveldb that while still not perfect in this scenario, is significantly improved.

0 Likes

#13

Having the same problem, I tried clearing the Index dir but that didnt seem to help. I am running 3061 on OSX 10.9.2

0 Likes

#14

Try turning indexing off:

1 Like

#15

btw, this issue is still present with the most recent build (3074). Sublime’s been chewing on a zero-byte index file, taking 3-6% cpu all the time… deleting the index file (as per datihein’s advice) totally helped to resolve the problem/

0 Likes

Build 3124 Show Definition
#16

I was having this issue on build 3103. Large cpu load even when idle. Wiping the index as suggested did the trick.

0 Likes

#17

Having this issue with 3122, tried deleting the Index directory with no luck either. Most of my packages are themes which I dont think should cause an indexing issues.

0 Likes

#18

Did you look at the console to see if there were any messages about indexing?

Do you see a percentage in the status bar, towards the right-hand side of the window?

Finally, how many files are in your project? Does you project primarily use a syntax that is not included by default with Sublime Text?

0 Likes

#19

Hi,

I just noticed this problem too. I’m on Win7, 3124. It looks like it’s an indexing problem and deleting the index folder helps for about 20 minutes but then a bunch of workers build up trying to index the same file over and over again. he last two lines are repeated ~100 times, here’s the relevant bits from conosole:

DPI scale: 1
startup, version: 3124 windows x32 channel: stable
executable: /C/Program Files (x86)/Sublime Text 3/sublime_text.exe
working dir: /C/Program Files (x86)/Sublime Text 3
packages path: /C/Users/moehr/AppData/Roaming/Sublime Text 3/Packages
state path: /C/Users/moehr/AppData/Roaming/Sublime Text 3/Local
zip path: /C/Program Files (x86)/Sublime Text 3/Packages
zip path: /C/Users/moehr/AppData/Roaming/Sublime Text 3/Installed Packages
ignored_packages: ["Markdown", "Vintage"]
pre session restore time: 0.189779
startup time: 0.279779
first paint time: 0.289779
first paint time: 0.289779
recreating index
reloading plugin 
...
reloading plugin TodoReview.TodoReview
plugins loaded
Package Control: No updated packages
worker 10964 appears stuck while processing file /C/Users/moehr/Documents/GitHub/shots/tools/node_modules/browser-sync/node_modules/browser-sync-ui/node_modules/connect-history-api-fallback/README.md, killing process
worker 13880 appears stuck while processing file /C/Users/moehr/Documents/GitHub/shots/tools/node_modules/browser-sync/node_modules/browser-sync-ui/node_modules/stream-throttle/node_modules/limiter/README.md, killing process
...
0 Likes

#20

@mattmoehr See [Solved] High CPU Usage in Beta 3124

0 Likes

#21

I put the binary_file_patterns thing in place and when I did the restart … boom… upgraded to 3126. Doubly fixed now. Thanks!

0 Likes

#22

Thanks so much for the workaround! My activity monitor was showing ~200 in energy impact and after I created a new Index dir it’s now down to ~30 when idle. Cheers!

0 Likes

#23

Disabling file indexing fixed the problem for me.

0 Likes

#24

Thanks, renaming the Index folder and creating an empty new one brought my CPU usage from 10% down to 0.5%
Worked for me on Ubuntu 17.10 with a 4.10.0-37-generic kernel using Sublime Text 3.0, Build 3143.
~/.config/sublime-text-3/Index

Hope this helps others.

0 Likes