Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?


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.


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


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.


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


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


It's written in CoffeeScript, so unless they rewrite in C++ using WebAssembly would make it slower.


That itself (rewriting in C++) to make it faster in the browser would be hilarious.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: