[oblio]

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).

[Klathmon]

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]

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]

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).