4 ms·

Question from the uninitiated: in the 'old days', you'd write or expose a C library. Most languages support C APIs without too much work and you don't need to s

Question from the uninitiated: in the 'old days', you'd write or expose a C library. Most languages support C APIs without too much work and you don't need to serialize/deserialize data structures. Although the described approach has some advantages (a plugin is separate from the Neovim process, can run across a network, etc.), I wonder if in some situations this doesn't give to much overhead. E.g. if someone is scrolling fast, do you really want to communicate with all plugins over a named pipe or socket, doing messagepack serialization/deserialization?

stinos 12y ago
Good point, but I assume a plugin only receives events it subsribed for, so it's not that for any event all plugins have to be notified. Also consider that the combination of serialization/local pipe/deserialisation may sound like something huge, but in reality probably only takes a couple of mSec. On the other hand: if it really goes over TCP/IP on another machine on another network, the lag should be noticable. But I doubt there are many plugins like that. On a sidenote: C apis are still used widely. And there are enough libraries out there to put an extra IPC layer on top of it so the'll behave the same as this one (i.e. can communicate though pipe/socket/... of choice).
kansface 12y ago
Vi was designed to work over a 300 baud modem. The throughput needed for a text editor is minimal (and still is). A C API would avoid the extra overhead, but no one is interested in writing cross platform unicode/binary safe plugins in the language. Also consider that buggy plugins that live in other processes won't crash the editor.
- stesch 12y ago
  By the way: 300 bps, not 300 baud. Baud is something different and you can transfer a lot more bits per second with 300 baud than just 300.
  - chongli 12y ago
    No, 300 baud. This comes from a direct quote by Bill Joy[0]: "No. It took a long time. It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem." [0] http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_gift/ http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_g...
  - davidp 12y ago
    Although you're technically correct (since baud connotes the rate of change of the signal and not the rate of data communicated over that signal), modems didn't start sending more than one bit per baud until we got to higher data rates. At the time vi was written, 300 baud was in fact equivalent to 300 bps and the terms were used interchangeably.
bla2 12y ago
MacVim uses the same model: Every MacVim window talks to one vim process behind the scenes. It seems to work very well in practice.
- danieldk 12y ago
  I have never profiled where the bottleneck is, but if I had relativenumber and cursorline set, I could see it literally redraw the screen (on both Intel and nVidia GPUs). Luckily, it's a bit better now on my MacBook Air 2012 and the latest MacVim. But it used to be so bad that I often unset these options.

stinos 12y ago

Good point, but I assume a plugin only receives events it subsribed for, so it's not that for any event all plugins have to be notified. Also consider that the combination of serialization/local pipe/deserialisation may sound like something huge, but in reality probably only takes a couple of mSec. On the other hand: if it really goes over TCP/IP on another machine on another network, the lag should be noticable. But I doubt there are many plugins like that. On a sidenote: C apis are still used widely. And there are enough libraries out there to put an extra IPC layer on top of it so the'll behave the same as this one (i.e. can communicate though pipe/socket/... of choice).

kansface 12y ago

Vi was designed to work over a 300 baud modem. The throughput needed for a text editor is minimal (and still is). A C API would avoid the extra overhead, but no one is interested in writing cross platform unicode/binary safe plugins in the language. Also consider that buggy plugins that live in other processes won't crash the editor.

stesch 12y ago
By the way: 300 bps, not 300 baud. Baud is something different and you can transfer a lot more bits per second with 300 baud than just 300.
- chongli 12y ago
  No, 300 baud. This comes from a direct quote by Bill Joy[0]: "No. It took a long time. It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem." [0] http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_gift/ http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_g...
- davidp 12y ago
  Although you're technically correct (since baud connotes the rate of change of the signal and not the rate of data communicated over that signal), modems didn't start sending more than one bit per baud until we got to higher data rates. At the time vi was written, 300 baud was in fact equivalent to 300 bps and the terms were used interchangeably.

bla2 12y ago

MacVim uses the same model: Every MacVim window talks to one vim process behind the scenes. It seems to work very well in practice.

danieldk 12y ago
I have never profiled where the bottleneck is, but if I had relativenumber and cursorline set, I could see it literally redraw the screen (on both Intel and nVidia GPUs). Luckily, it's a bit better now on my MacBook Air 2012 and the latest MacVim. But it used to be so bad that I often unset these options.