Advice against using msgpack about neovim

[Olivia5k]

I disagree. The protocol will be responsible for simple things like a j or k keypress. It's paramount that such things are as responsive as possible, and using a binary protocol will save some milliseconds. It might sound like a premature optimization, but I think that it will be pretty important.

Then again, it's basically a balance between developer ease of debugging and core responsiveness.

[joehillen]

Encoding and decoding a complex protocol adds much more latency than slightly larger message sizes.

[felipecrv]

Can't be true. I'm sure this is not the case for number encoding.

We can't antecipate how much communication will happen between client apps.
Using msgpack is a safer bet.
On Feb 23, 2014 7:51 AM, "Joe Hillenbrand" [email protected] wrote:

Encoding and decoding a complex protocol adds much more latency than
slightly larger message sizes.

Reply to this email directly or view it on GitHubhttps://github.com//issues/67#issuecomment-35828855
.

[joehillen]

So I've thought it over and researched it some more, and I concede that msgpack is in fact a superior protocol technology. Having the type and length built-in and at the beginning of each record is much easier to encode and decode. It's also a huge advantage that there is a native binary type.

The arguments that json is native in several languages is a wash because json-rpc is still a request/response protocol and it would be adviced to use a well travelled library (for which there really isn't).

And as for debugging, I'm not even sure it's possible to inspect the communication over a UDS (without maybe modifying the kernel) so that argument is also not relevant.

Good luck.

[Olivia5k]

You might be right, yeah.
Do you agree that speed and responsiveness should be the deciding factor? Whatever the solution, the key thing is that it needs to be as fast as it possibly can.

[joehillen]

I believe the point of making it async is so that the responsiveness doesn't matter.

I guarantee the bottleneck of the communication will not be the pipe between apps. There is absolutely zero benefit to adding msgpack in the middle just because it's the hot new thing.

Whichever protocol is chosen, it should be used in a way that makes swapping it out easy anyway. It makes the most sense to me to start with json-rpc because it will enable quicker development. If it's not good enough then swap it out for msgpack.

[retrohacker]

I thought msgpack was used to reduce message size for saving bandwidth on the network. If neovim communicates with applications on the same machine, will we actually get any benefit from using it? I think the above comments are right, encoding/decoding is going to be more expensive than sending large messages across stdin/stdout.

[ashleyh]

My thoughts, in no particular order:

• I doubt that it will take 'milliseconds' to en/decode a single keypress in json
• Given that there is some notion of coupling the GUI to a backend with this protocol, responsiveness is important
• Given that the traffic is not initially intended to go over a network, message size is less important
• Simplicity is good but json is not the simplest possible thing to en/decode
• Unix domain sockets are nice and all but we are also targeting Windows

[retrohacker]

JSON isn't the simplest thing to encode/decode, but almost every language
has great libraries built around the task making it simple for people to
write scripts consuming the data. Responsiveness is the most important
thing, and I do agree with that. But the second most important thing is the
ease of extending neovim. We don't want to sacrifice ease of extending the
application in favor of shaving a few microseconds off somewhere.

@chris, I agree from the coding side of things that it should be structured
in a way we can swap out protocols with no problem. That being said, once
it is released we are kinda stuck with what is decided on.

William Blankenship
_Aspiring Computer Science _Major

and Mathematics MajorPhone: [phone]Office: Faner Hall Room 2036,

Southern Illinois University,
Carbondale, IL 62901

On Sun, Feb 23, 2014 at 12:23 PM, Ashley Hewson [email protected]:

My thoughts, in no particular order:

• I doubt that it will take 'milliseconds' to en/decode a single
  keypress in json
• Given that there is some notion of coupling the GUI to a backend
  with this protocol, responsiveness is important
• Given that the traffic is not initially intended to go over a
  network, message size is less important
• Simplicity is good but json is not the simplest possible thing to
  en/decode
• Unix domain sockets are nice and all but we are also targeting
  Windows

Reply to this email directly or view it on GitHubhttps://github.com//issues/67#issuecomment-35837002
.

@Crackerz Yeah, I meant during the prototyping stage, before it's really made a public API.
@ashleyh I imagine we'll have to use different IPC mechanisms for posix and windows anyway, wouldn't we? E.g., Chromium uses socket pairs on posix and named pipes on windows. http://src.chromium.org/svn/trunk/src/ipc/ipc_channel.h

[ShaneDelmore]

In response to messagepack being used to reduce size sent over the network, that is not it's main intent. json gzipped is usually smaller. Messagepack has libraries for a ton of languages and is often much faster and has a smaller memory footprint to serialize/deserialize when compared to json. I have often seen numbers of 4-5x faster thrown around but in my last project where I converted from json to msgpack I saw over 20x improvement.

[retrohacker]

@ShaneDelmore you have me convinced. Msgpack is the way to go.

[lefb766]

@chriswatkins Although Chromium uses different IPC mechanisms, neovim shouldn't. If neovim use different IPCs for different platform and offer new plugin architecture onto it, its new plugins would have to alter their IPCs using for interacting with neovim depending on which platform they're running on. I suppose Chromium's IPC implementation doesn't construct APIs and its plugins usually don't have to care about platforms.

@lefb766 I don't see why plugins would have to care about the IPC mechanism Anyway, I don't have any experience with cross platform IPC. Pipes probably work fine.

[lefb766]

@chriswatkins I've took a mistake and used "IPCs" to describe alternative methods to stdin/stdout. Using the original idea of the new plugin architecture described on README.md, plugins can use just stdin/stdout to interact with neovim on any platforms. I thought that using different methods for different platform can add some complexity for developing cross platform plugins.

[tarruda]

@joehillen Neovim will just link against msgpack official implementation, so there no premature optimization(optimization was done by msgpack contributors). From the complexity point of view, theres little difference between using a json library or a msgpack library right?

Also, Unix domain sockets can be implemented as a separate process that multiplexes the editor output/input with multiple clients. There will probably be a 'neovim server' implementation on top of libuv(which uses domain sockets on unix and named pipes on windows)

From the plugins point of view there will be little difference, as msgpack and json seem to have implementations in most common programming languages. Also, both formats are very simple to implement from the scratch.

For locally connected neovim instances the difference between json or msgpack would be insignificant, but as explained in the fundraiser, it will be possible to have vim running in one machine with multiple GUIs connected via SSH for example. For these scenarios, especially with slower connections, I think that msgpack approximate 30% reduced size could make a difference.

Here are the msgpack advantages I considered before choosing it over json:

• smaller and apparently faster, there are some benchmarks that shows about 30% in size reduction, and theres seems to be a lot speed of optimization in the C official implementation.
• The streaming feature provided by the C implementation. Neovim will probably receive lots of incomplete msgpack documents, this feature greatly simplifies parsing.

JSON also has some advantages of its own:

• Simple debugging via a terminal
• Its supported out of box by web browsers, making it possible to write web UIs without having to write a serializer/deserializer

We can still enjoy the JSON advantages by using some kind of msgpack->json translation layer running between the server and the client(a websocket server could easily perform this translation for example)

All msgpack-specific code will go into a separate module so replacing would be easy if necessary. I'm closing this for now as there are more important issues to focus on.