Sublime Text consuming a lot of memory and cpu usage

[devin]

I am running the latest release of sublime text 3 on ubuntu 18.04 and it is consuming a lot of ram and cpu. The ram usage shoots up to 800-900Mib averaging at about 700Mib and the cpu usage of about 25-30%

I have just 2-3 files open each with about 100 lines of code. I don’t have any large folders open.

Here is the console info:

startup, version: 3211 linux x64 channel: stable
executable: /opt/sublime_text/sublime_text
working dir: /
packages path: /home/vinamra/.config/sublime-text-3/Packages
state path: /home/vinamra/.config/sublime-text-3/Local
zip path: /opt/sublime_text/Packages
zip path: /home/vinamra/.config/sublime-text-3/Installed Packages
ignored_packages: [“Vintage”]
pre session restore time: 1.44381
font face “” could not be found, defaulting to “Monospace”
startup time: 2.31381
first paint time: 2.84023
git: tracking working dir /home/vinamra/Desktop/cpp
reloading plugin Default.arithmetic
reloading plugin Default.auto_indent_tag
reloading plugin Default.block
reloading plugin Default.colors
reloading plugin Default.comment
reloading plugin Default.convert_color_scheme
reloading plugin Default.convert_syntax
reloading plugin Default.copy_path
reloading plugin Default.detect_indentation
reloading plugin Default.echo
reloading plugin Default.exec
reloading plugin Default.fold
reloading plugin Default.font
reloading plugin Default.goto_line
reloading plugin Default.history_list
reloading plugin Default.indentation
reloading plugin Default.install_package_control
reloading plugin Default.kill_ring
reloading plugin Default.mark
reloading plugin Default.new_templates
reloading plugin Default.open_context_url
reloading plugin Default.open_in_browser
reloading plugin Default.pane
reloading plugin Default.paragraph
reloading plugin Default.paste_from_history
reloading plugin Default.profile
reloading plugin Default.quick_panel
reloading plugin Default.rename
reloading plugin Default.run_syntax_tests
reloading plugin Default.save_on_focus_lost
reloading plugin Default.scroll
reloading plugin Default.set_unsaved_view_name
reloading plugin Default.settings
reloading plugin Default.show_scope_name
reloading plugin Default.side_bar
reloading plugin Default.sort
reloading plugin Default.switch_file
reloading plugin Default.symbol
reloading plugin Default.transform
reloading plugin Default.transpose
reloading plugin Default.ui
reloading plugin CSS.css_completions
reloading plugin Diff.diff
reloading plugin HTML.encode_html_entities
reloading plugin HTML.html_completions
reloading plugin ShellScript.ShellScript
plugins loaded
Running g++ “/home/vinamra/Desktop/2cpp/segTree/ram.cpp” -o “/home/vinamra/Desktop/2cpp/segTree/ram” && “/home/vinamra/Desktop/2cpp/segTree/ram”
font face “Times” could not be found, defaulting to “Monospace”
Running g++ “/home/vinamra/Desktop/2cpp/segTree/ram.cpp” -o “/home/vinamra/Desktop/2cpp/segTree/ram” && “/home/vinamra/Desktop/2cpp/segTree/ram”

Please Help me out in fixing this issue, Thanks

[qgates]

It may be plugin related. Try a portable install of Sublime without any plugins installed and see how that compares. If that improves things, start disabling plugins in your regular copy, restarting sublime each time, to nail down the offending plugin.

[FichteFoll]

It may be plugin related.

The console log doesn’t indicate any third-party plugin being loaded.

Consuming a few hundred MB of RAM is normal after several hours of usage, but your screenshot shows that ST has been running for only 7 minutes. You did, however, run a build system twice. Does your g++ call produce a lot of output that ST needs to store?

[devin]

No it does not ,actually the code I built was actually just empty c++ template it produces no output. and even if I don’t run build after startup the RAM consumption is still the same.

[qgates]

What’s the total memory and swap space in your system?

[devin]

Memory - 7.7 GiB
Swap space - 1.6 GiB

[qgates]

Hmm… as @FichteFoll said it’s not unusual for me to see up to 10% RAM in use by Sublime especially after several hours with multiple tabs/windows and/or projects open. However, that does seem a bit aggressive after just a few minutes with no extra plugins installed. Do you have any projects/directories loaded, possibly symlinking others? Sublime’s indexer will by default trawl everything it can find in loaded directories; that can cause a bump in CPU and RAM usage for the first x minutes of use, the time that takes depends on directory size, number of indexable files, whether you have SSD/spinny, and general machine speed. I noticed 26% CPU which suggests that indexer threads are running; see how it is after some time.

edit. Take a look at Help…indexing status to see what’s going on with indexers

[qgates]

Ok, so your screenshot indicates 7m of CPU time. Assuming your loaded directory is small, at 25-26% CPU after 7m I’m guessing one of your indexer threads is stuck, which might suggest a file that’s causing the indexer grief. If things don’t improve can you dump an ls -lRh of your loaded directory?

[devin]

vinamra@vinamra-HP-Pavilion:~/Desktop/2cpp$ ls -lRh
.:
total 32K
-rw-rw-r-- 1 vinamra vinamra 2.0K Oct 20 16:25 d1.cpp
-rwxrwxr-x 1 vinamra vinamra 19K Oct 20 16:33 r1
-rw-rw-r-- 1 vinamra vinamra 2.6K Oct 20 16:33 r1.cpp
drwxr-xr-x 2 vinamra vinamra 4.0K Oct 20 12:28 segTree

./segTree:
total 52K
-rw-rw-r-- 1 vinamra vinamra 1.4K Oct 20 11:36 cer.cpp
-rwxrwxr-x 1 vinamra vinamra 19K Oct 20 12:28 ram
-rw-rw-r-- 1 vinamra vinamra 2.0K Oct 20 12:28 ram.cpp
-rwxrwxr-x 1 vinamra vinamra 19K Oct 20 11:37 xeniaandbits
-rw-rw-r-- 1 vinamra vinamra 2.9K Oct 20 11:37 xeniaandbits.cpp

[qgates]

And I’m guessing the only directory you have loaded into sublime is 2cpp? Very light directories, no big files, binary etc… strange that your indexer is stuck. Are you still seeing ~25% cpu?

Only thing I can think is that something in your build targets r1, ram, xeniaandbits may be tripping up the indexer. I would think Sublime would recognise these as binary and leave them be but there might be a bug here. Try renaming your outputs to .out and configuring Sublime’s indexer to ignore .out files.

[devin]

How can I configure sublime’s indexer . It would be really helpful if you could share some link to a tutorial
.

[devin]

I tried seeing the indexer status. It shows idle, here is the screenshot.

PS : Ram consumption is around 2GiB now

[qgates]

Yes, something’s not right. Open up settings and add the following to the settings in the right hand pane (user settings). Take care that your JSON syntax is correct (every key value pair should be appended with a comma, the last one in the list being optional):

"index_exclude_patterns": ["*.log", "*.out"],
"binary_file_patterns": ["*.jpg", "*.jpeg", "*.png", "*.gif", "*.ttf", "*.tga", "*.dds", "*.ico", "*.eot", "*.pdf", "*.swf", "*.jar", "*.zip", "*.out"],

All I’ve done here is taken the defaults (which can be seen from the left pane) and added *.out as a match pattern. Save your prefs and restart sublime once you’re done.

[devin]

Thanks @qgates I think it worked as now ST is not taking RAM above 100MiB at max

[jfcherng]

@wbond Would it worthy adding *.out into default ST’s settings (either binary_file_patterns or index_exclude_patterns)?

[wbond]

Is the idea that this will handle a.out from C compilers?

[jfcherng]

Yes. Specifically, only a.out since it’s the default output binary for compilers like gcc. Maybe treat it as the same with a .exe file under Windows. In that case, add it to file_exclude_patterns.

[qgates]

Though I think there’s a reasonable case for adding .out to binary_file_patterns and index_exclude_patterns, there is a wider issue here: the indexer going rogue while processing inappropriate files. @wbond does the indexer have some kind of intelligence to determine whether files should be processed (ie. a way to determine text vs. binary files)? I’d always assumed it did; perhaps there’s some room to improve it.

The problem is that in the POSIX world filetypes often aren’t determined by file extension, and both binary and text files often don’t have extensions.

I think it’s worth adding this to the issue tracker (@devin?). If the output of g++ isn’t being identified as binary by Sublime’s indexer, that’s something that should be rectified.