Closed dylan-chong closed 6 years ago
https://github.com/w0rp/ale/blob/master/README.md#faq-my-battery-is-sad Look at this FAQ entry and change your settings.
Right, this does help with CPU usage but it does not actually fix the problem. The problem is that multiple lint processes can be started at the same time, which is a waste of CPU resources.
Perhaps some better solutions would include:
On 7/06/2018, at 6:22 PM, w0rp notifications@github.com wrote:
https://github.com/w0rp/ale/blob/master/README.md#faq-my-battery-is-sad https://github.com/w0rp/ale/blob/master/README.md#faq-my-battery-is-sad Look at this FAQ entry and change your settings.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w0rp/ale/issues/1637#issuecomment-395306748, or mute the thread https://github.com/notifications/unsubscribe-auth/AQrCbeBtkJpB7A9TfDHe-pOTbcHC9MS6ks5t6MbBgaJpZM4UdxQo.
Killing an existing process for the lint just before starting the new one
That's what ALE does, NeoVim just isn't good at doing that. NeoVim had a bug where it didn't create processes in a process group and then kill the group like Vim 8 does, but I believe that was supposed to have been fixed in a recent version. Maybe their bug fix didn't work. Try the same workflow in Vim 8 and see if it does a better job. If it does, then there's still a bug in NeoVim they should fix.
Maybe there's a bug in ALE you could try to fix, but I think ALE is doing everything it should. Have a look at ale#engine#RunLinters
and follow the logic there.
Here's the NeoVim bug I referenced: https://github.com/neovim/neovim/issues/6530
Waiting for processes to end wouldn't work, as that would give you invalid results. Killing them does, if the Vim client actually does what you told it to do.
aha! That bug looks like it was solved in 0.3, which still has not been released yet (they haven't released since November last year!!!) I've just read tested this bug again using versions v0.2.2 and the bug is replicated, but using v0.3.0-1336-gcf92a7628 the bug appears to be fixed. I must have tested the bug using the wrong version of nvim
Okay, sounds good to me. This problem has been raised a few times, and it will thankfully be solved in the next release. (0.3)
Fingers crossed they release before i grow old...
I'm still seeing this with neovim
0.3.1 and the latest ale
installed with plug
.
If I open a lot of .ex
files then a whole ton of linter processes start. I thought the LSP was only supposed to start a single process?
Current Filetype: elixir
Available Linters: ['credo', 'dialyxir', 'dogma', 'mix']
Enabled Linters: ['credo', 'dialyxir', 'dogma', 'mix']
Suggested Fixers:
'mix_format' - Apply mix format to a file.
'remove_trailing_lines' - Remove all blank lines at the end of a file.
'trim_whitespace' - Remove all trailing whitespace characters at the end of every line.
Linter Variables:
Global Variables:
let g:ale_cache_executable_check_failures = v:null
let g:ale_change_sign_column_color = v:null
let g:ale_command_wrapper = ''
let g:ale_completion_delay = 100
let g:ale_completion_enabled = 1
let g:ale_completion_max_suggestions = 50
let g:ale_echo_cursor = 1
let g:ale_echo_msg_error_str = 'Error'
let g:ale_echo_msg_format = '%code: %%s'
let g:ale_echo_msg_info_str = 'Info'
let g:ale_echo_msg_warning_str = 'Warning'
let g:ale_enabled = 1
let g:ale_fix_on_save = 0
let g:ale_fixers = {}
let g:ale_history_enabled = 1
let g:ale_history_log_output = 1
let g:ale_keep_list_window_open = v:null
let g:ale_lint_delay = 200
let g:ale_lint_on_enter = 1
let g:ale_lint_on_filetype_changed = 1
let g:ale_lint_on_save = 1
let g:ale_lint_on_text_changed = 'never'
let g:ale_lint_on_insert_leave = 0
let g:ale_linter_aliases = {}
let g:ale_linters = {}
let g:ale_linters_explicit = 0
let g:ale_list_window_size = v:null
let g:ale_list_vertical = v:null
let g:ale_loclist_msg_format = v:null
let g:ale_max_buffer_history_size = 20
let g:ale_max_signs = v:null
let g:ale_maximum_file_size = v:null
let g:ale_open_list = v:null
let g:ale_pattern_options = v:null
let g:ale_pattern_options_enabled = v:null
let g:ale_set_balloons = 0
let g:ale_set_highlights = 1
let g:ale_set_loclist = 1
let g:ale_set_quickfix = 0
let g:ale_set_signs = 1
let g:ale_sign_column_always = v:null
let g:ale_sign_error = v:null
let g:ale_sign_info = v:null
let g:ale_sign_offset = v:null
let g:ale_sign_style_error = v:null
let g:ale_sign_style_warning = v:null
let g:ale_sign_warning = v:null
let g:ale_statusline_format = v:null
let g:ale_type_map = {}
let g:ale_use_global_executables = v:null
let g:ale_warn_about_trailing_blank_lines = 1
let g:ale_warn_about_trailing_whitespace = 1
Command History:
(started) ['bash', '-c', 'cd ''/home/jesse/projects/foo'' && mix help credo && mix credo suggest --format=flycheck --read-from-stdin ''/home/jesse/projects/foo/test/foo_web/plugs/authorization_test.exs'' < ''/tmp/nvim3ZPvdm/13/authorization_test.exs''']
(started) ['bash', '-c', 'cd ''/home/jesse/projects/foo'' && mix help dialyzer && mix dialyzer < ''/tmp/nvim3ZPvdm/14/authorization_test.exs''']
(started) ['bash', '-c', 'cd ''/home/jesse/projects/foo'' && mix help dogma && mix dogma ''/home/jesse/projects/foo/test/foo_web/plugs/authorization_test.exs'' --format=flycheck']
(started) ['bash', '-c', 'cd ''/home/jesse/projects/foo'' && MIX_BUILD_PATH=''/tmp/nvim3ZPvdm/15'' mix compile ''/home/jesse/projects/foo/test/foo_web/plugs/authorization_test.exs''']
Am I missing something?
See this FAQ entry: https://github.com/w0rp/ale#5xiii-will-this-plugin-eat-all-of-my-laptop-battery-power
If anything is running too often, configure ALE to run programs less often. If neovim isn't killing processes properly, tell them to fix it, or try Vim instead.
With 2 .ex
files open, and g:ale_lint_on_text_changed = 'never'
I still see dozens of processes. My CPU seems to max out when I use the mix
linter, so I now only have credo
enabled. That being said, when I save a file, dozens of Erlang processes are created. They stick around for a few seconds, then they are killed. So it seems like there might be a couple of issues here... mix
linter going off the rails and the credo
linter booting up too many processes?
When I run mix credo
only one Erlang processes is created.
Maybe neovim/neovim#6530 didn't fix the issue after all? Is anyone else seeing these issues?
Maybe you can configure mix
to only run in a single process, or disable the linter completely, if it consumes too many resources.
I've disabled the mix
formatter and set the credo
formatter to only run on file save.
I'm still seeing a whole bunch of processes with the credo
checker enabled, more than I see when I run mix credo
from the command line.
I'm guessing that so many multiple processes is actually a bug, but I'm not sure where to report it. I have not seen that behavior in using mix format
. Is this a neovim
thing, an ale
thing or a mix/credo
thing? Tough for me to tell. Thanks for your help!
neovim
, but more likely credo
is at fault.
Could this be related to #2084? Compiling an entire project usually spawns a lot of erlang processes.
Information
VIM version
NVIM v0.3.0-1336-gcf92a7628 (also replicated on the latest stable build 0.2.2) Build type: Release
Operating System: mac 10.13.4
:ALEInfo
What went wrong
Many duplicate linting processes can be created
Reproducing the bug
Steps for repeating the bug:
aa<cr>aa<cr>
several times until you see several duplicate linting processes in htopI have been able to replicate this with credo (elixir) and eslint (js)
This is very annoying because my CPU gets maxed out relatively easily through normal vim usage. My normal vim usage involves going in and out of insert mode pretty frequently,