[vim/vim] Documentation: A more clear word on effect of terminal jobs (#7763)
reportaman
The document, which is admirable, is still not reassuring for real world workload in terminal emulator built into Vim.
I came across a neovim plugin page, that says it is not recommended to run long jobs within terminal emulator built inside neovim as that can slowdown neovim experience. Is that expected to be the case with Vim's implementation/handling of internal terminals? If yes is there a way to not affect a slowdown while running multiple terminal instances that are heavy.
Screenshot of the advice of neovim plugin:
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Christian Brabandt
well, if you run long running jobs that of course has a runtime cost. Vim needs to handle that job and if it outputs something, Vim also needs to take of that. So I would say this is not unreasonable to expect some slowdown. If you can run it from outside of Vim, this is most likely more efficient and faster. Remember Vim is an editor, not a terminal.
Dominique Pellé
>
> The document, which is admirable, is still not reassuring for real world
> workload in terminal emulator built into Vim.
> I came across a neovim plugin page, that says it is not recommended
> to run long jobs within terminal emulator built inside neovim as that can
> slowdown neovim experience. Is that expected to be the case with Vim's
> implementation/handling of internal terminals? If yes is there a way to
> not affect a slowdown while running multiple terminal instances that are heavy.
multi-threaded. Starting a terminal with a job that keeps printing on the
terminal makes Vim slow indeed, to the point of being almost unusable.
Just try this:
:terminal yes test
Then press CTRL-w CTRL-w to go to the regular buffer and notice that
Vim is slow. But this is not a common scenario. Generally, running
regular commands in the Vim terminal is fine.
Regards
Dominique
vim-dev ML
>
> The document, which is admirable, is still not reassuring for real world
> workload in terminal emulator built into Vim.
> I came across a neovim plugin page, that says it is not recommended
> to run long jobs within terminal emulator built inside neovim as that can
> slowdown neovim experience. Is that expected to be the case with Vim's
> implementation/handling of internal terminals? If yes is there a way to
> not affect a slowdown while running multiple terminal instances that are heavy.
multi-threaded. Starting a terminal with a job that keeps printing on the
terminal makes Vim slow indeed, to the point of being almost unusable.
Just try this:
:terminal yes test
Then press CTRL-w CTRL-w to go to the regular buffer and notice that
Vim is slow. But this is not a common scenario. Generally, running
regular commands in the Vim terminal is fine.
Regards
Dominique
reportaman
@chrisbra wrote:
Vim needs to handle that job and if it outputs something, Vim also needs to take of that.
Well I get the latter, what if I pipe the output of the process being run in that terminal to some file (which is not loaded in any vim buffer). Will that too interfere with vim's speed? I mean from Vim's standpoint it should be just a modified buffer who's contents are not changing.
@vim-ml I thought both neovim and Vim-8 are multithreaded... Though as far as I can imagine, there should be some main event loop in the GUI that periodically reads a status value to see what is the status of terminal process. Though at modern processor speeds, reading a few status registers (one per open terminal) shouldn't cause slowness. I wonder how the switches like ++hidden would playout with regards to performance... only Bram can enlighten us :)
—
You are receiving this because you were mentioned.
Bram Moolenaar
Bram Moolenaar
If the job has output that needs to be displayed, obviously that is work to be done. So that "yes" test slows down Vim because it's busy updating the display.
If you run a job in the background without any traffic on the input/output channels, there should be no load at all.
I don't think this is an actual issue, therefore closing.
—
You are receiving this because you were mentioned.
Gabriel Dupras
Here is an example where there is very noticeable slowdown.
--vim clean
:source $VIMRUNTIME/plugin/netrwPlugin.vim
:Explore
:terminal ++hidden yes test
Now, inside the netrw window, move the cursor up and down by holding down the j and k keys. The cursor moves noticeably more slowly and less smoothly than if yes test was running in a terminal outside Vim.
Also, the problem is much worse in GVim than in Vim, to the point where GVim might hang and become completely unresponsive:
--gvim clean
:terminal ++hidden yes test
Now try doing anything such as entering insert mode and typing something.
I'm seeing this in Vim 8.2.2453, on Kubuntu 20.10, in Konsole. I'm also using GVim built with GTK2.
—
You are receiving this because you were mentioned.
vim-dev ML
> @vim-ml I thought both neovim and Vim-8 are multithreaded...
in BeOS/Haiku. Window refresh is run from the window's event loop.
It is a bit hacky though, because it requires some added locking while
it looks in the text data structures. It is also passing GUI events
through a Vim Direct Communication Message Port (some people will get
the reference...) into the "normal vim thread". If Vim were really
multi-threaded, that part could probably be done in a cleaner way.
-Olaf.
--
Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
___ Anyone who is capable of getting themselves made President should on
\X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"
Shane-XB-Qian
// (#7703) i felt some yes, some no.
Here is an example where there is very noticeable slowdown.
that case probably more reproducible at Windows ?
—
You are receiving this because you were mentioned.