On my Mac (OS X 10.8.4) running Sublime Text 3 (build 3047), I see a base load of a little more than 6% CPU when Sublime is running but I’m not typing or scrolling.
I see the same 6-7% CPU whether I have any 3rd party packages installed or not. The packages I use don’t seem to have any impact on CPU usage.
I expect a text editor to consume very close to 0% (zero) CPU when not interacting with the user. Why does it matter? Laptop battery life is why it matters.
–
Dave Hein
Probably indexing your code for Goto Anything (Ctrl+Shift+R).
This is a one time thing, but can take a while if you added a big codebase to project.
With exactly the same setup I’m seeing 0% CPU utilisation when idling
wuub,
I don’t think it’s indexing any code. I have only about a dozen files in my project, mostly python with a few shell scripts and .gitconfig. Unless it’s trying to index the git repo under .git, but even that is really small. And I’ve let it run for hour, overnight, and it still is sucking about 6% CPU.
UPDATE: It turns out that the problem is indexing, but in an interesting way. See my two posts dated 29 August, below. The specific problem is identified and a workaround is offered.
–
Dave
It’s not likely down to indexing which, as wuub points out, should stop after a short time. Other thoughts:
Plugins could be responsible. Try disabling all your plugins temporarily to see if that fixes the problem. If it does, bring them in one by one until you find the offending plugin.
If you’re using a laptop with particularly aggressive power saving. Say your quad-core puppy runs at 3Ghz clock, but an aggressive power saving scheme downclocks the system to 400hz, or turns off some of the cores, or both - when it deems the system to be “idle”. In that case, processes using a tiny bit of CPU will actually look like they’re using a lot more, since 6% of 400hz is <1% of 3Ghz. Try putting your laptop into max performance profile and see what the CPU use is then.
Personally I don’t see sublime doing much of anything when idle. Rarely do I see anything other than 0 on the sublime process. If you’re editing particularly large files, or editing across a network, this could also have a minor impact on CPU as sublime will “poll” files and/or swap stuff in and out.
If you’ve no plugins enabled and no files loaded and still seeing 6%, well, you got me… Perhaps there’s something Mac-specific going on here, as I use Sublime only on Linux and Windows.
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:
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%.
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
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.
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
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).
BIG thanks on that workaround! This was making my fan kick on and drive me insane.
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.
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%.
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.
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
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/
I was having this issue on build 3103. Large cpu load even when idle. Wiping the index as suggested did the trick.
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.
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?
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 ...