Closed kovetskiy closed 7 years ago
vheon
commented
7 years ago Issue has reproduced to ycm cpp code base too.
Can you tell us which file did you try? So we can try ourself and see if we can reproduce. Also do you see this happening as soon as you open the file? Or do you have to do something to see the RAM usage increase?
kovetskiy
commented
7 years ago @vheon see stderr ycm log for messages like:
2017-04-30 21:26:36,759 - INFO - Adding buffer identifiers for file: /home/operator/.vim/bundle/YouCompleteMe/third_party/ycmd/cpp/ycm/tests/IndexForLetter_test.cpp
YouCompleteMe/third_party/ycmd/cpp/ycm/tests/IndexForLetter_test.cpp
This happening after 2-3 seconds after opening file (seems like ycmd collecting something, may be libclang doing something?), but memory usage does not increases (or just little bit) while editing opened files (moving cursor, writing something for triggering ycm completion).
vheon
commented
7 years ago I'm on mac so I'm not sure if there is something going on with libclang but after opening all the files listed in your stderr and I get a final memory usage of 350Mb. The noticeable bumps are when we load ycm_core.cpp which uses boost::python and when we load tests/main.cpp which uses gmock.h. I didn't dig up further for now though.
ru-wang
commented
7 years ago I have the similar problem here. I also use Arch Linux(kernel 4.9.11).
Here is the output of vim --version:
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Apr 26 2017 07:49:10)
Included patches: 1-586
Compiled by Arch Linux
Huge version with GTK3 GUI. Features included (+) or not (-):
+acl +file_in_path +mouse_sgr +tag_old_static
+arabic +find_in_path -mouse_sysmouse -tag_any_white
+autocmd +float +mouse_urxvt +tcl/dyn
+balloon_eval +folding +mouse_xterm +termguicolors
+browse -footer +multi_byte +terminfo
++builtin_terms +fork() +multi_lang +termresponse
+byte_offset +gettext -mzscheme +textobjects
+channel -hangul_input +netbeans_intg +timers
+cindent +iconv +num64 +title
+clientserver +insert_expand +packages +toolbar
+clipboard +job +path_extra +user_commands
+cmdline_compl +jumplist +perl/dyn +vertsplit
+cmdline_hist +keymap +persistent_undo +virtualedit
+cmdline_info +lambda +postscript +visual
+comments +langmap +printer +visualextra
+conceal +libcall +profile +viminfo
+cryptv +linebreak +python/dyn +vreplace
+cscope +lispindent +python3/dyn +wildignore
+cursorbind +listcmds +quickfix +wildmenu
+cursorshape +localmap +reltime +windows
+dialog_con_gui +lua/dyn +rightleft +writebackup
+diff +menu +ruby/dyn +X11
+digraphs +mksession +scrollbind -xfontset
+dnd +modify_fname +signs +xim
-ebcdic +mouse +smartindent -xpm
+emacs_tags +mouseshape +startuptime +xsmp_interact
+eval +mouse_dec +statusline +xterm_clipboard
+ex_extra +mouse_gpm -sun_workshop -xterm_save
+extra_search -mouse_jsbterm +syntax
+farsi +mouse_netterm +tag_binary
system vimrc file: "/etc/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "/etc/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
defaults file: "$VIMRUNTIME/defaults.vim"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/libdrm -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -L. -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/local/lib -Wl,--as-needed -o vim -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE -lm -lncurses -lelf -lnsl -lacl -lattr -lgpm -ldl -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector-strong -L/usr/local/lib -L/usr/lib/perl5/core_perl/CORE -lperl -lpthread -lnsl -ldl -lm -lcrypt -lutil -lc -L/usr/lib -ltclstub8.6 -ldl -lz -lpthread -lieee -lmAfter opening 2\~3 files(200\~300 lines for each), the memory usage increases to over 1Gb(after 5~10 files, up to 3Gb). And I find that the memory usage inceases crazily while editing opened files(whether it is a comment line or code line). My project uses Eigen3 and some boost functions, is it because of that?
bstaletic
commented
7 years ago @ru-wang I don't know what's Eigen3, but boost libraries certanly can be heavy and cause that problem. Make an empty main() and include boosts bimap.hpp and see Vim, YCM and everything related slow down to a crawl.
So yes, heavy libraries can cause the issues you're experiencing.
Just for comparison, I'm an Arch user too and I've used YCM with no issues this year to work on bstaletic/eurobot2k17.
ru-wang
commented
7 years ago @bstaletic Thanks for reply. I tried and you are right. Just an empty main() with some boost&Eigen headers makes YCM take up over 700Mb of memory.
BTW, Eigen3 is a header-only template library. So it could be the case that compiling code with template can cause huge usage of RAM.
micbou
commented
7 years ago Duplicate of https://github.com/Valloric/YouCompleteMe/issues/184.
austinwiltshire
commented
7 years ago I don't believe this is a duplicate of #184
This issue is about the python2 executable consuming a lot of memory all at once.
xyz1001
commented
7 years ago I have the same problem
Oranzh
commented
6 years ago I have the same problem.
austinwiltshire
commented
6 years ago I was able to fix by turning off YCM's integration with tags. My tag file was huge. My impression upon reading other threads is that tags integration for YCM isn't being actively worked on so no optimizations are in sight. If you're seeing this issue, I'd see how large your tag file is and whether or not you've set YCM to pick it up.
Valloric
commented
6 years ago https://github.com/Valloric/ycmd/pull/894 is likely to help with the cases where tags files are huge, since those issues are caused by tons of candidates in the identifier completer and the linked PR reduces the memory consumption per-candidate by 94% (by completely changing the internal architecture in amazing ways).
ghost
commented
5 years ago @Valloric I still get huge java memory usage, 1.13 GB right now with one file open.
bstaletic
commented
5 years ago Who is responsible for memory usage? YCM/ycmd or the java server called jdt.ls? If it's the latter, which is likely, you should talk to jdt devs.
Issue Details
I've been using YCM for working with big c/cpp project and noticed that ycmd python2 (same as with python3) process is eating more than 1GB RAM after opening 5 files, if 10 files, than 2gb. Issue has reproduced to ycm cpp code base too.
Diagnostic data
Output of
vim --versionOutput of
YcmDebugInfoContents of YCM, ycmd and completion engine logfiles
stderr:
stdout:
OS version, distribution, etc.
Arch Linux (rolling release, everything is up to date)
ycm git submodules:
my ycm settings:
I've tried to disable ycm_collect_identfiers_from_tags and ycm_collect_identifiers_from_comments_and_strings (actually I didn't use tags), but nothing changed.
How I can help to debug the issue? May be provide vim profile log or something else?