8 ms·

A possible (very early) start for this could be https://github.com/google/xi-editor https://github.com/google/xi-editor UIs and actual functionality are comple

A possible (very early) start for this could be https://github.com/google/xi-editor https://github.com/google/xi-editor UIs and actual functionality are completely separate implementations. Loading and displaying text are entirely decoupled, so the display doesn't have to care if the actual file is 10kb or 2gb in size.

dilap 10y ago
super-early-days, but this looks philosophically very much in the right place.
- MildlySerious 10y ago
  There's a talk about it, too, if interested: https://www.youtube.com/watch?v=SKtQgFBRUvQ https://www.youtube.com/watch?v=SKtQgFBRUvQ I'm hoping to find the time to get more comfortable with Rust and try to contribute at some point
flukus 10y ago
Yet another with a client server architecture. It makes no sense in a desktop application to add the performance overhead of IPC and serialization to every user interaction.
- duaneb 10y ago
  What is the performance overhead like? I can't access the app right now but I'd be highly surprised if it caused a noticeable input latency. Or are you talking out of your ass?
  - flukus 10y ago
    It's a whole lot of unnecessary serialization and deserializtion, even if the performance is not noticeable it's a waste of cpu cycles. From looking at similar projects, overhead tends to be in the millisecond range per call, so performance depends on the ammount of back and forths. Add in all the overhead for serialization and IPC and in practice it looks a lot like the round trip in same data center latency here: https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html https://people.eecs.berkeley.edu/~rcs/research/interactive_l...
    - oblio 10y ago
      > even if the performance is not noticeable it's a waste of cpu cycles. If the performance hit is not noticeable, nobody really cares about the waste of CPU cycles. Especially since a text editor uses something like 1/10 the resources a large, complex program uses anyway.
      - falcolas 10y ago
        Well, you would care if you're on a battery for any appreciable amount of time. Some IDEs go as far as to offer low power modes where they throttle external plugins.
      - flukus 10y ago
        And when everyone thinks that we end up with the same performance we had 20 years ago on vastly improved hardware.
- legulere 10y ago
  It's important to note that here the client server architecture is asynchronous and multiple. This allows it to actually decouple slow interactions as auto-completion from things that need low latency such as typing. You actually see this in many IDEs that more features make editing feel more sluggish. This shouldn't happen with this structure.
  - thomasahle 10y ago
    Is auto completion really useful, if it's a lot slower than the rest of the program? Maybe if a part is too slow, you should either optimize it or get rid of it?
    - oblio 10y ago
      Well, considering that as far as developer tools are concerned many of the best sellers are IDEs with Intellisense (intelligent code completion, based on syntax and semantics)...
    - viraptor 10y ago
      Sometimes you want the autocompletion, sometimes you don't. You can do it in synchronous style, where you have 2 choices: a) delay the typing when the user doesn't care about the autocomp, b) require an extra action to activate autocomp when the user wants it. You can also do it async style and have neither of the drawbacks - if the user types too quickly, the autocomp just doesn't show up.
  - flukus 10y ago
    > It's important to note that here the client server architecture is asynchronous and multiple. Both can (and have) been achieved without a client server architecture.
- captainmuon 10y ago
  I'd take the overhead of a client-server architecture over the overhead of rendering the whole UI in HTML (electron apps) any time. Also I think that the marshalling you need for IPC is not so different than the boxing and conversion that you have under the hood if you write in an interpreted language, e.g. Python or JavaScript.
  - hamstergene 10y ago
    Serialization alone is like, at least one order of magnitude slower than dynamic typing, and IPC has other os-specific overheads on top of that. Remote calls are so costly the whole architecture of a system has to be designed with them in mind.
  - baldfat 10y ago
    I was 100% in your boat after experiencing Atom. I have a 8 year old re-purposed Linux box (OpenSUSE) for work. That took a LONG time to be okay with our Windows based IT Department. I changed my mind over two electron editors/IDE. I use RStudio and it is really been getting so fast on my old computer that I can't tell anymore. VS Code by Microsoft is so fast and nimble that I have been using it 75% of the time with no felt overhead. It really is an amazing piece of software in terms of speed, now the ram usage is still much higher but for my uses I don't notice it at all on my 8 year old Dell corporate computer.
  - flukus 10y ago
    > I'd take the overhead of a client-server architecture over the overhead of rendering the whole UI in HTML (electron apps) any time. It's not an either/or problem though.
beefsack 10y ago
For those interested in the editor, keeping an eye on the subreddit is worthwhile too: https://www.reddit.com/r/xi_editor https://www.reddit.com/r/xi_editor

dilap 10y ago

super-early-days, but this looks philosophically very much in the right place.

MildlySerious 10y ago
There's a talk about it, too, if interested: https://www.youtube.com/watch?v=SKtQgFBRUvQ https://www.youtube.com/watch?v=SKtQgFBRUvQ I'm hoping to find the time to get more comfortable with Rust and try to contribute at some point

flukus 10y ago

Yet another with a client server architecture. It makes no sense in a desktop application to add the performance overhead of IPC and serialization to every user interaction.

duaneb 10y ago
What is the performance overhead like? I can't access the app right now but I'd be highly surprised if it caused a noticeable input latency. Or are you talking out of your ass?
- flukus 10y ago
  It's a whole lot of unnecessary serialization and deserializtion, even if the performance is not noticeable it's a waste of cpu cycles. From looking at similar projects, overhead tends to be in the millisecond range per call, so performance depends on the ammount of back and forths. Add in all the overhead for serialization and IPC and in practice it looks a lot like the round trip in same data center latency here: https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html https://people.eecs.berkeley.edu/~rcs/research/interactive_l...
  - oblio 10y ago
    > even if the performance is not noticeable it's a waste of cpu cycles. If the performance hit is not noticeable, nobody really cares about the waste of CPU cycles. Especially since a text editor uses something like 1/10 the resources a large, complex program uses anyway.
    - falcolas 10y ago
      Well, you would care if you're on a battery for any appreciable amount of time. Some IDEs go as far as to offer low power modes where they throttle external plugins.
    - flukus 10y ago
      And when everyone thinks that we end up with the same performance we had 20 years ago on vastly improved hardware.
legulere 10y ago
It's important to note that here the client server architecture is asynchronous and multiple. This allows it to actually decouple slow interactions as auto-completion from things that need low latency such as typing. You actually see this in many IDEs that more features make editing feel more sluggish. This shouldn't happen with this structure.
- thomasahle 10y ago
  Is auto completion really useful, if it's a lot slower than the rest of the program? Maybe if a part is too slow, you should either optimize it or get rid of it?
  - oblio 10y ago
    Well, considering that as far as developer tools are concerned many of the best sellers are IDEs with Intellisense (intelligent code completion, based on syntax and semantics)...
  - viraptor 10y ago
    Sometimes you want the autocompletion, sometimes you don't. You can do it in synchronous style, where you have 2 choices: a) delay the typing when the user doesn't care about the autocomp, b) require an extra action to activate autocomp when the user wants it. You can also do it async style and have neither of the drawbacks - if the user types too quickly, the autocomp just doesn't show up.
- flukus 10y ago
  > It's important to note that here the client server architecture is asynchronous and multiple. Both can (and have) been achieved without a client server architecture.
captainmuon 10y ago
I'd take the overhead of a client-server architecture over the overhead of rendering the whole UI in HTML (electron apps) any time. Also I think that the marshalling you need for IPC is not so different than the boxing and conversion that you have under the hood if you write in an interpreted language, e.g. Python or JavaScript.
- hamstergene 10y ago
  Serialization alone is like, at least one order of magnitude slower than dynamic typing, and IPC has other os-specific overheads on top of that. Remote calls are so costly the whole architecture of a system has to be designed with them in mind.
- baldfat 10y ago
  I was 100% in your boat after experiencing Atom. I have a 8 year old re-purposed Linux box (OpenSUSE) for work. That took a LONG time to be okay with our Windows based IT Department. I changed my mind over two electron editors/IDE. I use RStudio and it is really been getting so fast on my old computer that I can't tell anymore. VS Code by Microsoft is so fast and nimble that I have been using it 75% of the time with no felt overhead. It really is an amazing piece of software in terms of speed, now the ram usage is still much higher but for my uses I don't notice it at all on my 8 year old Dell corporate computer.
- flukus 10y ago
  > I'd take the overhead of a client-server architecture over the overhead of rendering the whole UI in HTML (electron apps) any time. It's not an either/or problem though.

beefsack 10y ago

For those interested in the editor, keeping an eye on the subreddit is worthwhile too: https://www.reddit.com/r/xi_editor https://www.reddit.com/r/xi_editor