emacs-ycmd
emacs-ycmd copied to clipboard
abingham
Slow startup when loading 100s of C++ files
If one uses something like desktop-save-mode to load 100s of C++ files at startup, YCM will prevent emacs from coming up.
OK, this isn't too surprising in retrospect. Does the situation improve if you remove mode-enabled from ycmd-parse-conditions? This may not be the proper solution, but it might alleviate the pain in the short-term.
That alleviates the pain. The problem now would be that this doens't enable ycmd when I open a new file, right? Why does ycmd interfere with startup - I would have expected the ycmd commands to be sent asynchronously...
When you open 100 files then you send for all files a request to the ycmd server that the should be parsed. I am not sure how the deferred package is handling requests internally, but I guess for every request it polls for a respond? And if there are 100 request it is waiting for 100 responses. That may slow down Emacs.
I have encountered this also quite often because I use the desktop-save-mode myself. Starting up with a lot of C++ files, Emacs hangs for quite a while until all files are parsed.
Right. When mode-enabled is in ycmd-parse-conditions, you're asking emacs-ycmd to parse a file as soon as it enters ycmd-mode, i.e. typically as soon as it's opened. By removing that from the list you defer a file's first parse until some other event triggers the parse (e.g. saving it, depending on your configuration).
So, you should still be getting full ycmd support if you make the change I suggested, you just won't get a parse on file open. If things do not seem to be working when you make this change, let me know...there's a bug somewhere.
As for @ptrv's analysis, that sounds about right. We do send the requests asynchronously, but it wouldn't surprise me if there are limits to the performance of the deferred system. You might also just be suffering from general system lockup since you're requesting hundreds of C++ compilations at one.
In summary: if you're satisfied that the ycmd-parse-conditions change meets your needs, then I'll close this out, and I'll also make a note in the README. If there are still problems, let me know and we'll see what we can do.
Do you mean do the parse when the buffer first becomes visible or "has the user's attention"? We might be able to manage something like that. Emacs 24.4 introduced focus-in-hook which I think will allow us to detect when the buffer has focus. We can probably arrange things so that a buffer can be parsed the first time it gain focus. But I don't know the precise semantics of focus-in-hook; it may not do exactly what I'm thinking.
Sorry this took so long...lots of irons in the fire. Take a look at the parse-on-focus branch. This adds a new option for ycmd-parse-conditions called first-focus. If this is in ycmd-parse-conditions, then we'll request a parse when a buffer gets focus, but only if that buffer has never been parsed before.
If it works as planned, you should be able to replace mode-enabled with first-focus, avoiding the large up-front compile burden. Give it a shot and let me know if it works for you. It seems to work on my end, but I don't have a project with hundreds of files to open at once!
@ptrv Can you take a look at the change and let me know if it looks reasonable to you?
Wow, thanks! Will take me a bit to get back - I'll need to get it into the hands of my users first :)
@r4nt We've merged in a change by @ptrv that should address the problem you're seeing. It takes a different approach than the parse-on-focus branch, fixing some issues with desktop.el integration.
To use this change, modify your ycmd-parse-conditions to include buffer-focus and remove ycmd-mode. If everything works as planned (as it seems to!), after a buffer has been visible for 1 second it will get parsed. But buffers which aren't visible (i.e. which aren't displayed in a window) won't be parsed.
Let us know if it works or if it gives you any problems.