Scrolling through files by holding down `j` or `h` causes slowness about nyaovim HOT 17 CLOSED

Hmm... it may be performance issue. I think there're too many rendering events from nvim and they're stacked.

from nyaovim.

I have a similar issue. My issue is, I cannot press and hold HJKL to move around. I have to press and release time else nothing happens.

I will investigate to detect the source of the problem if it is a config option.

UPDATE:
It is not a config option as I just try nyaovim with a blank init.vim.

from nyaovim.

@khalidchawtany

Sorry, I missed your comment because this issue has 'enhancement' tag 🙇

Hmm..., could you check <C-d> causes the same issue? Input with modifier and input without modifier are not handled in the same place. (the former is handled with keydown event and the latter is handled with input event.) I want to isolate the problem.

from nyaovim.

Sorry, I was out of Internet coverage for the past two weeks and will be for many upcoming days too (hopefully).

I forgot to mention that pressing ctrl-d and ctrl-f work as expected. However, HJKL has this issue. Excuse me, If I will not be able to answer any question you may have, as I will be offline :)

from nyaovim.

I can confirm that <C-d> / <C-u> work as expected. I would like to add that I experience lag anytime the "screen" moves (i.e.: scrolloff) even if I don't hold down the movement keys.

from nyaovim.

Scrolling screen causes redraw of entire window (e.g. <C-e>, <C-y>). All rendering events are passed from Neovim via msgpack-rpc. And it seems that the RPC is slow as long as I profiled in previous. So we might improve msgpack5rpc package.

from nyaovim.

Could anyone confirm that <C-e> and <C-y> cause this issue?

I think this is because the difference of processing key input.
If input is with modifier key, it is processed in keydown event (e.g. <C-e>). But if input is without modifier key, it is processed in input event of <input> element (e.g. j).

This is because we can't catch compositionstart/compositionend events on keydown event. I want to confirm this issue is derived from the difference.

from nyaovim.

If msgpack decoding is the bottleneck (rhysd/neovim-component#2), then https://github.com/tarruda/libmpack may help, once it is ready. cc @tarruda

from nyaovim.

@justinmk @tarruda

Thank you for the notice. Although I'm not familiar with Node.js native extension (e.g. overhead on calling C from Node), it looks very helpful.

BTW, I wonder why msgpack-c was not adopted.

from nyaovim.

BTW, I wonder why msgpack-c was not adopted.

We are using msgpack-c already, but libmpack is intended to be easy to embed in non-C hosts such as node.js. So instead of using nodejs's mspack library, NyaoVim could ship with libmpack.

@tarruda gave a good explanation of the motivation for libmpack in gitter which I'll paste here:

libmpack is meant to hold most logic of a neovim client in a cross-language way(as long as a language can bind to C)

ZyX-I:

What’s the problem with currently used msgpack implementation except that it could be more memory-efficient (and, likely, faster) in some cases?
Can you describe in libmpack README why this project exists and how it compares to msgpack-c?

tarruda:

These are the main reasons:

• It is not trivial to simply include its files into another project(eg: a lua C module) since it relies too much on C99 features and compilation with -Wconversion issues a bunch of warnings. You need to build the library and link against it, which IMO is cumbersome for a simple serialization library that is being embedded into other projects(lua or node.js modules for example).
• It couples msgpack serialization format with a set of predefined C typedefs. This means the user almost always has to recursively convert the allocated structures into some other application-specific format, especially if binding to another language.
• It doesn't work without allocating memory. For example, you can't send/receive simple primitives without a msgpack_sbuffer_t(which is then dynamically extended by msgpack internal functions).
• msgpack-rpc lacks a proper C implementation. I actually haven't found a sane msgpack-rpc implementation even in other languages such as ruby, they are all very complicated(Eg: separate server and client APIs, have hard dependencies platform-specific on event loop libraries).

As I said, I want to use it as the base of a C neovim client that can be easily bound to any language, but I also wanted it to be flexible enough to use in any C project
For example, it has no system dependencies so it can be used in kernel development(eg: communicate with userspace using msgpack-rpc via netlink sockets)

It also has an extra bonus that is not immediately visible: If you use -O3 and limit its API usage to a single file and use the amalgamation(and define MPACK_API as static) it will not emit any symbols, the whole thing will be inlined into a single loop in your function(even user-provided callbacks are inlined)

from nyaovim.

@justinmk

Thank you very much for the detailed information. I understood 😃

from nyaovim.

@rhysd c-y and c-e work perfectly. It is only hjkl keys that has to be released and pressed to repeat the key.
When I press and hold L I see a pop up suggesting another letter as shown in the screenshot below.

from nyaovim.

@khalidchawtany

c-y and c-e work perfectly. It is only hjkl keys that has to be released and pressed to repeat the key.

Thank you for your confirming! I understood.
I'm going to go to U.S. this week on business trip. So the fix will come in the end of this week or beginning of next week.

When I press and hold L I see a pop up suggesting another letter as shown in the screenshot below.

Hmm, are you installing some UI plugins? If not, I think it is derived from text field in <input> element (e.g. Input Method).

from nyaovim.

@khalidchawtany that looks like its coming from OSX
@rhysd you might be able to stop that from happening using autocomplete="off" when not in insert mode.

from nyaovim.

@johnhamelink you were right it is coming from OS X. Disabling press and hold solves the problem for me.

defaults write NSGlobalDomain ApplePressAndHoldEnabled -bool false

from nyaovim.

@rhysd / @justinmk For sequential 1-line scrolling, I find it unlikely that the bottleneck is node-msgpack5. In this case neovim sends ui_scroll notifications followed by line redraws of the invalidated area, which is a short payload and wouldn't result in noticeable deserialization overhead even if the msgpack implementation is very inefficient.

The best way to handle ui_scroll notifications is to use a coordinate transformation function from the UI's native toolkit. Here is how the python gtk UI does it, which results in smooth scrolling even though the high level UI logic is implemented in python.

For page scrolling, more lines need to be redrawn, so a slow msgpack implementation could cause the bottleneck, and in this case libmpack would solve the problem. But this is not the only possible bottleneck: Since the UI must maintain the entire screen state in memory, it can be slow to handle burst updates resulted from both scrolling and region redraws. For this we also need to have a C client for Neovim, which will be built on top of libmpack.

After this C client is released(a relatively small layer on top of libmpack), most Neovim UIs built on top of it will get a significant performance boost.

from nyaovim.

Thank you for the comments. I think the problem is that input without modifier (e.g. j, k) is caught at <input> text field. And inputting to text field has some side effects. They may make NyaoVim slow.

I'm going to go to U.S. this week on business trip. So let me check your comments more and try to fix this problem at this week-end or beginning of next week.

from nyaovim.