0

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.

  • 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 Mark Dec 14 '18 at 17:58
  • Fast, good, cheap: pick two – whatsisname Dec 14 '18 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 Reinking Dec 15 '18 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. – gdanov Dec 18 '18 at 22:14
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.