3 ms·

I wonder whether a modern modularized architecture might be the better way to handle this. Similar to neovim where you have a backend which communicates with a

I wonder whether a modern modularized architecture might be the better way to handle this. Similar to neovim where you have a backend which communicates with a detatched frontend and other backends over some rpc-mechanism. Refactor the existing emacs to work headless and become the legacy-core, while also establishing channels to attatch any other core and frontend.

gpderetta 7y ago
An important optimization discussed in the video is to optimize through call into C code (i.e elisp->C->elisp). adding RPC at the boundaries would go in the opposite direction.
- WhatIsDukkha 7y ago
  Well this is not to my taste but I take it as a proof of existence that an rpc at the boundary could make for some amazing things - https://github.com/rhysd/NyaoVim https://github.com/rhysd/NyaoVim
- slightwinder 7y ago
  It's optimization for a single process vs multiple processes. Additionally, when you free up your architecture and loose up the internal bindings between different areas, you sometimes can open chances for significant improvments which prior where not possible, thus still be faster with a "worse" solution. Considering how old GNU Emacs is, how much historical problems it has and how often you hear that this and that can't be optimized for this and that reason, this seems like such a situation where loosing up would open faster roads long term.
Myrmornis 7y ago
https://github.com/xi-editor https://github.com/xi-editor is an example of the architecture you're referring to I believe. Xi's README makes it clear that very high performance is one of the main goals: in particular it mentions the latency between keypresses and screen painting. To what extent does this RPC-based architecture limit performance compared to a single-process architecture? I know that the original author of Xi very much knows what he is doing, so I guess the answer is "it doesn't" -- I was just hoping to be educated on this point.

gpderetta 7y ago

An important optimization discussed in the video is to optimize through call into C code (i.e elisp->C->elisp). adding RPC at the boundaries would go in the opposite direction.

WhatIsDukkha 7y ago
Well this is not to my taste but I take it as a proof of existence that an rpc at the boundary could make for some amazing things - https://github.com/rhysd/NyaoVim https://github.com/rhysd/NyaoVim
slightwinder 7y ago
It's optimization for a single process vs multiple processes. Additionally, when you free up your architecture and loose up the internal bindings between different areas, you sometimes can open chances for significant improvments which prior where not possible, thus still be faster with a "worse" solution. Considering how old GNU Emacs is, how much historical problems it has and how often you hear that this and that can't be optimized for this and that reason, this seems like such a situation where loosing up would open faster roads long term.

Myrmornis 7y ago

https://github.com/xi-editor https://github.com/xi-editor is an example of the architecture you're referring to I believe. Xi's README makes it clear that very high performance is one of the main goals: in particular it mentions the latency between keypresses and screen painting. To what extent does this RPC-based architecture limit performance compared to a single-process architecture? I know that the original author of Xi very much knows what he is doing, so I guess the answer is "it doesn't" -- I was just hoping to be educated on this point.