On designing a cross-platform text editor that optimized for speed - I heard atom.io uses node.js, would it be slow? I heard sublime text uses C++, would it lots of effort to be cross platform and make GUI? I am trying to find out some of the best ways of achieving performance, cross-platform, easiness of making GUI and good maintainability.
4
-
Given that a text editor is almost certainly going to have a human in the loop I wouldn't make speed a critical factor in selecting a programming language to use. I'd probably not make it a factor at all.– High Performance MarkDec 14, 2018 at 17:58
-
Fast, good, cheap: pick two– whatsisnameDec 14, 2018 at 18:35
-
1@HighPerformanceMark I generally agree with that, though I've personally been frustrated with Electron app performance on low-end machines. Sublime scales much better on large files thanks to its lower memory overhead for being written in C++– Alex ReinkingDec 15, 2018 at 7:47
-
you'll need to select you target platform/hardware range, the expected file size, the expected overhead (coloring, structure parsing/visualisation) and benchmark. For "small" and "simple" files Electron may suffice, but without clear latency goal and target conditions/constraints range nobody can answer that question for you.– gdanovDec 18, 2018 at 22:14
Add a comment
|
1 Answer
Atom, VS Code, and Electron apps more generally trade a lot of development time for CPU cycles and memory on the end user's system. I've found both aforementioned editors quite sluggish on low to mid tier laptops, and they aren't particularly kind to the battery, either.
Still, they perform acceptably well on developer workstations and people generally like to use them, so they must be efficient enough for the business purpose.
From a software standpoint, editor response times rely on a large number of factors and scale with the number of modules that need to know about each keystroke. If you want to perform syntax highlighting, code completion, automatic indentation, integrate static analysis, etc. then it will be important to keep the UI thread IO bound. It should spend almost all of its time waiting on the user to do something. Architecting the rest of the editor to move compute bound tasks to worker threads that can asynchronously report their results to the UI will be most important. I also want to specifically call out the importance of having a good strategy for re-parsing modified text. It should scale with the amount of text that was changed, rather than the length of the document (as it would if you re-ran the parser on every keystroke)
Those concerns will dominate the perceived performance of your editor much more than the language you write it in.
