4 ms·

Same here. I have tried it a few times. The sole reason I'm not moving from Sublime is the speed of the editor.

• albasha 11y ago
  It will never be as fast as Sublime. Not before a few years at least.
  • landr0id 11y ago
    As much as I hate the idea of basically bundling Chrome with the application to get it to run, since this is essentially Chrome then wouldn't it be able to utilize WebAssembly in the future instead of the JavaScript engine?
    • Touche 11y ago
      It's written in CoffeeScript, so unless they rewrite in C++ using WebAssembly would make it slower.
      • cheez 11y ago
        That itself (rewriting in C++) to make it faster in the browser would be hilarious.
    • Matthias247 11y ago
      I don't think JS is the bottleneck. I think one of the bottlenecks is algorithms - because Visual Studio Code is much faster than Atom on the same node/electron platform. The other main bottleneck might be that the browser DOM is used for rendering, which is super flexible but probably not as fast as a more dedicated text editor GUI toolkit.
      • oblio 11y ago
        It's probably the architecture difference between Atom and VS Code. VS Code plugins run out of process and have access only to a limited set of APIs (http://code.visualstudio.com/docs/extensions/our-approach http://code.visualstudio.com/docs/extensions/our-approach).
        • Klathmon 11y ago
          I'm also convinced it's the syntax highlighting in atom that contributed to a massive amount of its "sluggishness". It uses regex with some off-the-wall engine that they chose because it supports just about every encoding under the sun. Many of the language syntax packages I looked at could easily improve their regex performance. Plus when you open a file as "plain text" or disable the syntax highlighting package much of the sluggishness goes away. I'd love to dive in and try and fix it myself but I won't have time to for a few months. The code itself isn't horrible just a little undocumented.
          • Matthias247 11y ago
            I think Sublime Text, Atom and now also VS Code use Oniguruma as their regex engine. Atom and code even use the same implementation (node-oniguruma) and the syntax highlighting definitions for the languages are often also the same - because they were ported from TextMate to Sublime and then to Atom and Code. So even if the engine is not perfect and the defined regexes might not be optimal for some languages - it still would not explain why Atom is slower than Code. My personal guess is that is because Code might use a more stream-like processing of the source files and does not have the whole files in memory (it also works with really big files - which Atom does not support) and that this does work better
            • Klathmon 11y ago
              Hmm I did not know that! You are probably right about the streaming system. It's interesting that atom doesn't do it that way (seeing as how streams are such an useful part of "server-side" javascript) Like I said at one point i'd really like to dive into this stuff and spend some time trying to figure out exactly what the problem is (and maybe help find a way to fix it).
  • paublyrne 11y ago
    Visual Studio Code seems much snappier than Atom, but is based on the same engine. So atom can be much faster.
    • tomc1985 11y ago
      Atom was much faster, back in the day!