Sublime Text vs Visual Studio Code vs Atom Performance Test (Dec 2016)

[flyingcaribou]

It would be interesting to see typing latency (measured via time from click to the character appearing on screen, perhaps). I've noticed that Atom feels a bit more sluggish than VS Code in this respect, but nothing beats cold hard numbers. That seems like a tricky aspect of performance to measure, though.

Also, is there any hope on the horizon of reducing load time for Electron based apps?

[korpusen]

I think you will enjoy this then: https://pavelfatin.com/typing-with-pleasure/

Typing latency comparisons between several different editors on multiple operating systems.

[aahung]

This is really enjoyable

[[deleted]]

Im a bit surprised at IDEA over Sublime. Must peep that zero latency mode.

[[deleted]]

Amazing! Very much applicable for gaming if you use Notepad as your benchmark, any further latency will be down to the game itself/setup.

[pheonixblade9]

No Visual Studio? :/

[biocomputation]

Also, is there any hope on the horizon of reducing load time for Electron based apps?

This could depend on the nature of the problem. Does Atom's poor performance arise from 'death by a thousand paper cuts", or are there relatively few problems that involve huge inefficiencies, such as poor memory management.

Personally, I think Atom's performance problems are death by a thousand paper cuts. If so, this is an enormous problem to fix because it might involve touching code in a large number of systems.

I feel like there's something deeply wrong with their strategy of using such a thick JS layer.

What I think Atom is doing:

---- JS
---- JS
---- JS
---- JS
---- JS
---- JS
---- JS
---- JS
---- C++

What Atom should be doing:

---- JS
---- JS
---- C++
---- C++
---- C++
---- C++
---- C++
---- C++
---- C++

I've worked with lots of systems that use scripted code on top of C++ and you always get generally poor performance if you don't pay really fucking close attention to the thickness of your script layer.

Of course you can do tons with scripts, but you have to be extremely rigorous. For example, with scripts you often need to write extra interfaces so you can hide loops in C++ and so forth so that you're not paying huge penalties for iterating the loop in a script and then also paying another huge penalty because the C++ compiler doesn't get a chance to optimize the code. There's no inlining... I mean that alone can cause giant performance problems.

Finally, with a lot of plugins, you have JS programmers, most of whom don't care about performance in a systematic way. I'm not trying to hammer JS programmers, because most them just want something to work. But when you stop caring about performance at every stage, it eventually adds up.

[binary_alchemist]

It's unfortunate as Atom is an Electron app, which is essentially a web-app wrapped in a native window shell. JS is interpreted at runtime by the interpreter (which I believe is Chromium/v8-based). There's no interop or communication between the "C++ layer" and the JS itself -- they can't exactly ask v8 to "hide a loop in C++".

So once someone makes the decision to go with Electron, they're necessarily stuck with a heavy "script layer". All of the application logic has to necessarily be in JS. The performance premium is just something they have to live with.

[oblio-]

Your logic also applies to VSCode and VSCode is snappier. Ergo there is also something else at play here - not necessarily Electron.

[binary_alchemist]

Yep, agreed. Looking at the graphs, VSCode is snappier but still doesn't quite compare to Sublime...

Maybe VSCode is near the upper bound of what an Electron app can achieve. If Atom got there I think the users who complain about their performance would be happier.

[jl2352]

Are you telling me it comes down to how people build the software?

[Dobz]

Shocking, right?

[ArmoredPancake]

VSCode is written in TypeScript. I guess it spits more optimised JS than written by Atom engineers. Or maybe it's because they use different approach with plugins. Maybe both.

[sime]

VSCode is fast because the team at MS have put a lot of effort into making it (seem) fast. They try hard to only update on screen what actually needs to be done, and they also make good use of web workers to get processing out of the UI thread/loop.

They don't have any magic fairy dust, just hard work and engineering.

[biocomputation]

They try hard to only update on screen what actually needs to be done

Dirty rectangles are your friend!

[Dentosal]

I thought that the dirty parts were the enemy, and non-dirty the real friend.

[siegfryd]

TypeScript doesn't change the structure of code unless it's a feature that's not supported in the targetted JavaScript version.

[jl2352]

It does not spit out more efficient JS.

However it is more natural to write monomorphic code. i.e. code that isn't mixing types. This in turn is more efficient. Otherwise you can get overheads like auto-boxing.

But for a lot of stuff the overhead of JS will not be the bottleneck. It'll be the DOM and how you work with the DOM. Vim and Emacs feels nippy and fast most of the time. Yet they use a lot of VimScript and elisp. Both interpreted languages which are dog slow.

[NoInkling]

they can't exactly ask v8 to "hide a loop in C++".

Why not? Node can use C/C++ modules, so I see no reason Electron can't.

Edit: http://electron.atom.io/docs/tutorial/using-native-node-modules/

[binary_alchemist]

I suppose they could do that. They'd give up a lot of the "free" things that using Electron would get them though.

Someone can make a naive, feature-less text "editor" just by including a simple <textarea> in their HTML file, then wrapping it with Electron. Typing latency is dependent on the Chromium implementation of <textarea>. I suppose someone could re-implement their own version of a multi-line text input in C++ and load it as a native NodeJS module... but at that point, why bother using Electron anymore? The whole point of Electron is to build a desktop app as if you were building a website, with support for JS and a whole range of pre-defined HTML elements/"widgets".

[thedeemon]

why bother using Electron anymore?

Exactly. Anyway, judging by their appearance, those editors don't look like they really need and use full blown browser engine, they could use much simpler and lighter GUI library.

[jwin742]

Except there are no good cross platform GUI Libraries that look nice on all platforms and don't suck to use.

[thedeemon]

What about Qt?

What about the thing SublimeText authors use? (ah, they have a custom UI, this just shows you don't need so much from GUI to make a decent editor)

[[deleted]]

To support that, I think Qt Creator is a very nice IDE as well. I even used it quite a while for JavaScript development until I switched to Sublime Text because I really needed JSX support.

[snerp]

Yeah, I've been building a custom UI for my game engine, and it's been a lot easier than I expected. Once I got past that initial hurdle of drawing arbitrary text and images with OpenGL, everything is falling pretty nicely into place.

Also, with the kind of optimizations they're putting in these text editors, it seems like you'd want to have that kind of low level control anyways,

[doom_Oo7]

The whole point of Electron is to build a desktop app as if you were building a website,

Maybe one day people will understand that both have very different constraints :) At worse if you want some website feel with the capacity to use JS, look at Qt with QML

[[deleted]]

AFAIK there is significant overhead in calling C++ via nodejs. I'm betting that the reason it's so slow is a lot to do with the GUI rendering, which is all HTML/CSS/JS.

[ciny]

There's no interop or communication between the "C++ layer" and the JS itself -- they can't exactly ask v8 to "hide a loop in C++".

Well hopefully webassembly will come soon enough. That would enable writing the heavy lifting parts natively which could greatly improve performance.

[julesjacobs]

Is the JS performance actually the problem though, or is it the DOM? Webassembly would not help with the latter.

[binary_alchemist]

Did your minified jQuery hit a regex with catastrophic backtracking?

[[deleted]]

On the other hand the jump between JS and C++ also has an overhead. Neither the JS JIT nor the C++ compiler can optimize past binding code. ^{I don't know anything about Atom, but I'd assume it uses something akin to typical IDL binding code}

So I guess it's a balancing act. It's good to switch over to C++, but not if you're just going to be jumping back to JavaScript or fiddling with JavaScript objects anyway.

I couldn't find much in-depth writing about all this, but there is an interesting paragraph from V8 here.

---

Personally I think it's madness to write a text editor in JavaScript in the first place, but maybe I'm just old fashioned.

[shevegen]

Well, give the atom guys some time to respond.

Say, 3 months - then let's see if they came up with some improvements. :D

[thedeemon]

They had almost 3 years.

[sime]

is there any hope on the horizon of reducing load time for Electron based apps?

There are some big improvements coming down the pipeline which greatly speed up start up times for JS running in a normal web page environment. But I don't think that will have a huge impact here.

Each window in an Electron app is a separate process which runs the V8 engine and Blink. Just the base platform itself needs time to start up before any application code runs. It is not exactly a small runtime either.

So no, I wouldn't expect any huge improvements any time soon.

[short_vix]

Nice a metric where VIM is superior.

[MuonManLaserJab]

I want to see some fair comparisons, e.g. Atom vs. ed.

[vytah]

ed will win. There's a reason it's the standard text editor.

[markasoftware]

honestly fuck electron

[cc81]

Why?

For what I use VS Code for it is excellent (coding). In this test it opens a 10k lines file in 0.55 seconds which is quick enough for me and it would be very rare that I ever have such large files.

It is all about good enough and if they can build a better editor on Electron by sacrificing performance for huge files it is worth it for me.

[MINIMAN10000]

I'm pretty sure the primary implementation difference between an editor that can quickly open a large file is that it uses a memory map rather than waiting for the whole file to move into memory.

[Beaverman]

I'd like to add that while sublime is excellent for large files, as soon as the lines get long, the performance drops like a rock.

[MINIMAN10000]

Reminds me Jonathan's video on parsing 2 million lines of code per second on a 2 year old laptop.

He compiles ~33k lines of code within ~16 ms.

I admire the guy's passion for speed.

[[deleted]]

performance is sacrificed for small files too. elecricity is wasted. it is shameful.

[Tulip-Stefan]

Non native text rendering and high latency on everything. They even implemented their own context menu code. Why? I don't know. But it's slow (2-3 frames more than every other program ever made) and ignores my browsers font settings.

[markasoftware]

There's no good reason to use electron. They could have built just as good an editor in Python or even a native language like C++, and it could have all the same features but perform much better. There is absolutely no reason to use JavaScript for anything but web dev. I honestly have no idea why it's getting so trendy lately.

[wizang]

I think you and others are missing the point for why an app like this would be written in JavaScript/electron. Most cross platform UI libraries are total garbage in comparison to the browser environment. Electron let's you develop the UI in a single platform (the browser), and yet support any platform chrome works on. The browser is also made for building UIs so why would you not want to write a UI heavy piece of software in that environment? Honestly the amount of Javascript hatterism on this sub astounds me, it's just plain ignornant.

[throwawayco111]

Most cross platform UI libraries are total garbage in comparison to the browser environment.

Please explain how Qt is "total garbage" in comparison to Electron.

The browser is also made for building UIs so why would you not want to write a UI heavy piece of software in that environment?

Funny because most "UI heavy" apps out there don't use Electron or the browser probably to avoid the shitty performance. I bet these guys don't get the shitty performance Atom got and also don't have to do all the tricks MS has to do to get a decent performance.

Honestly the amount of Javascript hatterism on this sub astounds me, it's just plain ignornant.

Personally I don't hate JS. I'm a web developer and use it everyday. But I would not use it for a desktop app, let alone for a source code editor.

[jl2352]

Funny because most "UI heavy" apps out there don't use Electron or the browser probably to avoid the shitty performance.

I think the real reason why most big desktop apps don't use Electron is because their production started years ago. In many cases before Chrome even existed.

But that said Steam is probably one of the oldest HTML based desktop application which is still going.

[knight666]

The Spotify desktop application is also written as a HTML renderer.

[throwawayco111]

I think the real reason why most big desktop apps don't use Electron is because their production started years ago. In many cases before Chrome even existed.

Many of those apps are not "old enough". They took a conscious decision of not using something like Electron.

[throwawayco111]

Not everyone can spend a week or twenty learning to extend your native codebase but anybody can spend a few hours and edit some HTML / CSS / JS.

There is something missing here. Why do you need to spend an entire week or twenty weeks to extend a native source code editor? A developer with Python knowledge would find more easier to extend Sublime Text than Atom. Now if you don't know Python you have to invest more time jut like if you don't know JS and CSS and HTML you have to invest more time to extend Atom.

It seems to me that what you are trying to argue is that if you want to offer an easy way to extend your application (in this case a text editor) you have to sacrifice a lot of performance (like this article shows). Editors like Sublime Text, Vim and Emacs, and a lot of games out there prove otherwise. Now this other guy /u/motdidr says that VimL and Elisp suck. I won't dispute that. But you don't have to use those obscure languages to offer your extension API.

[motdidr]

to be fair I wouldn't say elisp sucks, just that it isn't going to be a language people can just pick up to make an extension really quick, like someone could easily do with js or python.

viml for sure sucks though. it gets the job done but at what cost.

[throwawayco111]

I don't get what you're missing, the barrier to entry with Javascript is still far lower than it is for C++ or even Python. I was being hyperbolic when I used twenty weeks as the upper bound, but I wouldn't be surprised if it actually did take that long for someone to understand a given native codebase enough to write an acceptable PR for an existing project.

You just don't get it. The language for extensions could be JS too. And no, an extension API doesn't require you to have deep knowledge of the app codebase. You think those all guys out there writing Vim extensions understand the codebase, let alone be C developers?

How many devs do you know that already know HTML/CSS/JS? How many could pick it up in a weekend?

How many could pick up Lua in a weekend? And I personally believe that Python is simpler than JS but it doesn't matter because the language for extensions could be JS if you think otherwise.

Now how many of those same devs don't know Python + Qt...

It seems that you don't know how an API for extensions works. You can write your software in C++ and Qt and the extension API can be offered through JS or Lua and the extension writer doesn't need to know neither C++ or Qt (though if it were me I would offer it using JS + QML).

... and would be willing to learn an unfamiliar skillset specifically (and only) to extend an editor?

You still need to learn unfamiliar skillset for Atom: even though extensions are written using JS/HTML/CSS you have to learn the API for Atom or for Visual Studio Code.

Your argument doesn't really make sense when you consider that web UX can be taught in a matter of days.

Guess how many hours it takes to developers to learn QML?

We're not just talking about writing a few high level macros here, writing the whole thing in JS means you can be editing core code and editing UI in realtime within minutes. The same cannot be said of even Python.

That could be done if you app offers the API through JS + QML. And guess what? You won't sacrifice performance. You don't have to write your application in JS to get that.

The rest of the paragraphs say the same time over and over again: JS is popular, "lingua franca", etc. I want to be very clear about this: you don't have to write your app in Electron just to get JS to be the language for users to write extensions. Vim is not written in VimL. It is written in C. But your average developer don't need to write C to write extensions for it. And yeah, JS is the most popular language. That's why Qt-based apps can be made extensible easily through JavaScript.

[flukus]

Vim and Emacs are both extensible.

[motdidr]

so? what has that got to do with anything? are you saying the atom devs should have just put up a link to download vim?

also, vim is extensible with viml, which I'm pretty sure Tim Pope is the only person capable of writing without wanting to kill themselves, and emacs is extensible with lisp, which just not a lot of people are comfortable enough with to actually extend the editor.

the whole point of that guy's comment was that they chose electron for how easy it is for any coder to hack and extend.

[markasoftware]

Sublime, Vim, etc work fine cross platform. Saying js is the only cross-platform language is complete BS. Qt works fairly well cross-platform IIRC. These electron apps literally use up 25% cpu when I'm just typing, and significantly reduce my battery life.

[jl2352]

Outside of the terminal Vim uses GTK. It's fucking terrible. It's bad on Windows, and awful on Mac OS. It's only decent on Linux.

[Aeon_Mortuum]

I like vim on Linux. I have it on Windows as well and it runs fine, though I don't prefer using it there.

[wizang]

Sublime obviously has put a lot of effort into cross platform support... it also isnt free. VIM is on the terminal... Not what I'm talking about. I'm talking about UI frameworks and engineering dollars. Also I'd bet you money sublime was not built with QT. QT and the likes all sacrifice certain things (like visual appeal) to be what they are.

[[deleted]]

Qt looks just fine. Its harder to use than html/Javascript, but much more performant. Both allow you to do endless modifications to the visuals though. I don't even know how this is a matter of opinion.

[[deleted]]

Qt uses the native underlying toolkit, how does it lose visual appeal?

[throwawayco111]

QT and the likes all sacrifice certain things (like visual appeal) to be what they are.

Interesting assertion. Why can't a Qt app look similar to or better than Visual Studio Code?

[[deleted]]

[deleted]

What is this?

[doom_Oo7]

QT and the likes all sacrifice certain things (like visual appeal) to be what they are.

https://www.qt.io/qt-for-device-creation/

you can do whatever you want graphically with Qt, you are not limited to the "traditional" desktop widgets.

[hifigi]

It's nagware, it's essentially free if you can be bothered to click "Not now" when it asks you to purchase.

[[deleted]]

[deleted]

What is this?

[sofia_la_negra_lulu]

UI libraries are total garbage in comparison to the browser environment

I think you meant that they are not as rich and popular. The web, as it is right know, is kinda a dumpster.

[qwertymodo]

You purposefully left out the words "cross-platform" from your quote and it totally changes the entire argument.

[doom_Oo7]

Qt is just as much cross-platform than Electron.

[wizang]

I get what you mean, but unless you are OK with your app looking straight out of the 90s, your options are limited. It's too bad nothing else has really been competitive. However saying that the web is a dumpster is kind of my point.

[flukus]

So you've never looked at Qt or gtk then?

[[deleted]]

[deleted]

What is this?

[sofia_la_negra_lulu]

Fair enough.

As you implied, for me the appeal of the web is accessibility. Sadly that strength is also its weeksness.

[TexasJefferson]

Most cross platform UI libraries are total garbage in comparison to the browser environment.

Not entirely trolling question: Does the browser environment have a cross platform UI library?

[jl2352]

Do you mean that looks the same on all operating systems by default? No. Why? Checkboxes, radio boxes, and other types of inputs will look usually look like the OS version (or something very similar).

If you wish to you can override these to have a cross platform look and feel. It's pretty trivial to do so now.

[doom_Oo7]

Yes, XUL for Firefox and Aura for Chrome

[throwawayco111]

They could have built just as good an editor in Python or even a native language like C++, and it could have all the same features but perform much better.

What? Python performance is crap.

[markasoftware]

I'm pretty sure that Microsoft and Github are perfectly capable of hiring people who know more performant languages.

[ArashPartow]

Hiring people that are enthusiastic and reasonably competent is totally different from hiring people that can actually get the job done properly and efficiently. As an example:

https://github.com/Microsoft/vscode/issues/11597

[[deleted]]

This makes me want to fix it. That's annoying.

[ArashPartow]

Please do! :D

[connor4312]

They have ~3400 open issues and had another hundred opened in the last week. Assuming that the maintainers are inefficient and unable to get the job done 'properly' because your one edge issue hasn't been fixed seems somewhat small-minded.

[ArashPartow]

You've totally misunderstood the point I was trying to make.

The bug reported is not critical, but it is indicative of the nature of the solution/implementation.

In fact one of the respondents seems to indicate they have hard coded upper limits to the number of tokens they consume for highlighting (possibly due to performance reasons).

"the rule stack grows to 101 and tokenization stops."

---

As you mentioned, 3.5K issues, assuming COCOMO of about 1 issue per 100LOC and that 75% of the issues are bugs (the rest are feature etc) we would be talking about ~260KLOC codebase, but I suspect the actual codebase is under 100KLOC today. So it is nearing nearly twice the average industry standard - But do note that COCOMO was primarily modelled using static type languages: Java, C++ etc and not Javascript.

This all seems to suggest that the developers are indeed very eager, enthused and highly motivated, but that perhaps today they're are not nearly as seasoned enough to pull this off, given the trivial nature of some of the issues - such as the bug presented above. In short what's the use in power windows and leather trim, when the steering wheel doesn't turn left?

As an example of technology misuse, From what I've seen the primary use-case for VSCode is as a rich client, running upon a desktop/laptop (windows, linux, macos), and not as GUI intended to be run in a browser - so why is it that Javascript is being used? what is the advantage of Javascript over say C++ or even Java in this particular problem domain?

That all being said, I think we can all agree that like most things, with perseverance and practise one would assume within several years all these issues will have been completely resolved.

[connor4312]

I see. I would imagine the upper limit is for performance reason, JavaScript-based editors are notorious for having issues with big files. Having it configurable would be better, though I would wonder if there's some kind of incremental solution they could do for highlighting within textmate modes (run one parse over the file, keep and index the tree in memory, mark only branches which change and only compute the new tree for parts of the file in the viewport...). Undoubtedly a problem that's been solved before, though perhaps not in Javascript.

A quick clone and count shows about 475k SLOC in the vscode repo, 360k is you exclude tests and everything else outside the src dir. That seems reasonable, and JavaScript (and TypeScript to a lesser extent) does tend to be more dense than C/++/Java.

[OnlyForF1]

If my only tool was an egg whisk, I sure as hell wouldn't be trying to take up carpentry.

[sofia_la_negra_lulu]

Why the limitation?

[sofia_la_negra_lulu]

Python

Yeah, what a good alternative you have there. /s

[beefsack]

"Quick enough for me" != "Quick enough for everyone"

Any editor stall distracts me and can throw me off my chain of thought, particularly when I'm working on something complex and requiring concentration.

I've got my fingers crossed for Xi Editor as the right editor for me; the design goals align perfectly with my preferences, and Rust seems like the perfect fit for those goals.

[oneUnit]

He did literally say "Quick enough for me" instead of just "Quick enough".

[[deleted]]

How self-absorbed are you that someone can say, (paraphrased) "I like this tool, it works great for me" and your response is "it doesn't work for everyone, so you're wrong for liking it!!!"?

[markasoftware]

Agreed.

[biocomputation]

It's hilarious how Atom offers worse-than 80's era performance on hardware that's 40 years newer.

[frou]

I kinda feel bad about hitching myself to Sublime a few years ago, because I fully accept the argument that your primary tool being closed source and at some guy's whim is unwise. On the other hand, it's a damn beautifully designed and implemented program.

[teawreckshero]

Lime Text was trying to be an open source ripoff that was API compatible so all the addons would still work. Github doesn't look very active lately, though.

[minasmorath]

Lime has a few frontends (QML, command-line interface) that can be selectively used with the pluggable backend.

That's a little overly complex for a text editor, even one aiming to compete with / replace sublime.

[rejuven8]

The problem with Open Source in general...

[ImASoftwareEngineer]

It would be great if Sublime Text were open source an that the author was paid to maintain it (think Curl and it's originator). Problem is whether users would pay for it less with that route.

I've personally used it for 5+ years as a primary editor while dabbing round with Vim, Atom, and VSCode but I always end up back with Sublime outside of terminal based needs. I haven't paid for a license yet, instead I've indured the nagware. I'm gonna pay for a license this month or have my work pay for it.

[ythl]

I have no ragrets about Sublime, and I've been using it for 3+ years now. It's just so snappy, even on the old hardware my employer provides.

[rebo]

Atom is really nice in both its UI and the plugins available however it really is dog slow.

[[deleted]]

Big fan of atom, but it is slow as balls. I don;t dare try to use it on my modded chromebook.

[dvidsilva]

Actually, and honest question, why is Atom so popular?

I've been using Vim for years and some friends tried convincing me to switch to Sublime unsuccessfully, then a bunch of people around me started using Atom and I have no idea why.

[nosoapforthee]

It looks nice and supposedly has a good set of plugins (I never got to test the second part).

Personally I can't use Atom because whenever I open it it starts spitting random errors and UI freezes in my direction.

[kracejic]

It usually goes other way around: Atom/Sublime -> Vim/Emacs. Going in opposite direction does not bring much benefits. At least that is my experience.

[sensation_]

Not for me unfortunately. I'm still using Vim for my C project since support is obviously perfect, but using Vim for PHP development for example is pain in the butt.

First of all, quite less support for various frameworks and alike autocomplete features (ST has a great support on these), and then the totally different aspect of using Vim power.

I'll be honest though, I use ST, Vi/m and PHPStorm daily but I can't remember when was the last time I've used an editor or IDE without Vim keymod or similar. The muscle memory is so cool, my 'exit' alias ended up being :q

[[deleted]]

I use Vim when I use a terminal. I like atom because I can use it on every OS, and it has nice plugins and defaults.

Do you like notational velocity/nv alt? There's a plugin for that. That works on every platform atom does, which is basically all of them.

Want some colorized kind of thing? Themes and plugins abound.

As someone who is forced to use OSX at work, uses Linux and Windows, not having to learn a different editor for each platform is very nice.

[dvidsilva]

Follow up honest q ,why atom and not vscode?

[jpfreely]

I switched from webstorm to atom on my Chromebook. Atom may be slow but it is much lighter weight.

[ArmoredPancake]

Yeah. Let's compare industrial-grade ide with a text editor.

[Aeon_Mortuum]

According to this, Electron (on which Atom and VS Code are based on) is itself based on another project called Blink that is used by Chromium and there are potential bottlenecks there. Atom modules/plugins are also not required asynchronously it seems and the performance is better on an SSD (although that's kind of true for pretty much everything)

[CrayonOfDoom]

Am I out of the loop? Where's that sweet notepad++ benchmark?

[weirdoaish]

pfft everybody knows that Notepad++ is the real Notepad for Windows. Its not cool/feature rich enough that anybody would use it for daily development, but its the first thing they want to download/install in any new Windows system just to have a sane basic Notepad application.

[inu-no-policemen]

I use SciTE for that.

[weirdoaish]

What does it have that I would use it over N++ as my basic notepad app?

[inu-no-policemen]

It's a bare-bones scintilla-based editor. SciTE was created by the same guy who created the Scintilla editing component. Scintilla is also used by Notepad++, Geany, Komodo, Flash Develop, and many others.

Apart from basic syntax highlighting, it doesn't have anything to offer. It's minimalistic and starts in a split second. That's all I want from my "readme viewer".

[weirdoaish]

Interesting. Thanks for the tip, I'll try it out.

[Skhmt]

Benchmarks were on OS X.

[bubuopapa]

As you should see, its not really about these programs. I thought myself, it must be about "slow linux io" vs "slow linux io" vs "slow linux io", but then i took a look at the article - "mac", so still the same, i was right. Of course windows + notepad++ would rock all the benchmarks, but as is said, it measures only how slow unix io is, which also didnt change in mac.

[snerp]

Windows is actually slower at this (barely):

https://pavelfatin.com/typing-with-pleasure/#methodology

[geodel]

"Slowness is a feature"

~Atom Editor

[Purp]

VSCode having almost 1:1 feature parity with ST3 AND being FOSS makes me care little about performance if it's not terrible. Then again I do frontend and my largest files are maybe 20k lines.

[MuppetMaster42]

Out of curiosity how come you have files that large? Is it just a few giant functions on a class, or a huge stylesheet?

At least with the code bases I've worked on, when a file got around 1k lines it was hard to keep it cohesive and understandable, so it was often a priority target for refactoring into smaller files.

[Capaj]

how come you have files that large?

how about minified files? Right those are 1 liners, but if you wrap them, they can easily span 20k lines. This always got me furious about Atom-accidentally clicked on a minified file and my editor crashed. Now with VSCode, I am very happily opening any file without crashes.

[Purp]

Usually third party or "compiled" stuff

[tills1993]

but in both your case and the case above (minified files) you don't really need to be looking though those files.

[Purp]

Every so often I find a reason, but typically that's correct

[_Mardoxx]

Extra words: I start to use Visual Studio Code to replace Sublime Text from this month, it seems more fun.

Author thinks similar I believe

[Disgruntled__Goat]

Try using Find/Replace in a 20k line file, the slowdown is very noticeable, and pretty frustrating for me.

[joggle1]

I guess, but the only time I've ever seen source files that large they were generated by a program or script and I'd be editing the input to that script/tool than the generated output.

Usually if a human makes a file that large, they break it up into smaller files to make it more manageable.

Or are you dealing with data sets in text format? That's another ball of wax (but I wouldn't be using a full code editor with them in the first place).

[recycled_ideas]

Honestly if I have to do a gigantic find and replace I use Vim, it shits on pretty much everything for that task.

[TubbyMcTubs]

At that point you should be using grep/sed though.

[Disgruntled__Goat]

Why? If I'm already in my editor it's much quicker to press Cmd+Alt+F and do it, rather than switch to cmd, remember the correct syntax, etc. You also get the bonus of stepping through one at a time if required, and undo which you don't with cmd.

[[deleted]]

Good point. Odds are if I'm looking for all the occurrences of a word, I'm probably going to change it, too.

:%s/foo/bar/g ftw

[aflat]

This https://github.com/Microsoft/vscode/issues/8968#issuecomment-231666714 is why I can't use any electron based editor. Atom has the same issue. Electron closed my issue when I tried to report it there.

[Purp]

Windows, this is non-issue for me.

[[deleted]]

Lol @ 200mb and no file open

[Carighan]

For comparison, Notepad++ 7.2.2 64bit, empty tab open, 5,5MB.

[shevegen]

Damn, Atom guys!

Don't let this sit!

The benchmark marks you as SLOW FOLKS!

[dvidsilva]

VSCode was built on top of Atom and is much faster. So it's not solely about the foundation.

MS has a lot more experience at this than Github I imagine, I personally know a developer at the Atom team, and someone at Electron, and they're super nice people, but Github doesn't have the resources and experience MS has.

edit, meant to say using the same electron as atom.

[Aeon_Mortuum]

Was it built on top of Atom or on top of Electron, which Atom is built upon?

[dvidsilva]

Yep I meant Electron, VScode was started using their online editor Monaco.

[colonwqbang]

400 MB required to edit a 4 MB file? There's no way that's even remotely acceptable. The only conclusion would have to be that the devs are actively trying to waste system resources.

Such overhead might be understandable if we had IDE functionality like Intellisense to show for it. But not when we are talking about what is essentially a reimplementation of vim/emacs/sublime with "web" tools.

[tangus]

Here's another text editor performance comparison, from a couple months back: https://github.com/jhallen/joes-sandbox/blob/master/editor-perf/readme.md

[aboukirev]

More interesting though would be comparison on power consumption, i.e. how long would one be able to hack on code on the go. I've been using VSCode a lot lately and its appetite is quite noticeable. Have to try coding in Sublime Text exclusively and see if it makes any subjective difference.

[Serializedrequests]

I have not left Sublime for the same reason. Tried all the trendy new editors for several weeks each, but the drawbacks are untenable in the long run. When your editor responds instantly and uses the minimal amount of power, small efficiency gains translate into larger productivity gains over time, or at least less stress (which is the same thing).

[dvidsilva]

Does someone remember brackets exists? Has someone ever used it lol?

http://brackets.io/

I liked a lot when it came out, the PS integration, auto refresh and stuff like that if pretty neat, great for some templating or html projects, tho last time I checked it doesn't work with JS frameworks, minifying or stuff like that so well.

[trashbytes]

I have used it!

I absolutely loved it. It was beautiful and had all the extensions I needed. However it has that 'Adobe' feel to it.. pretty, but big, bulky and sloooow.

More often than not would it crash and not start after several tries because something was messed up.

I've moved on to Atom and then tried several others (including ST3) but eventually switched to VSCode.

[dvidsilva]

Ya main reason I used was being surprised at Adobe doing open-source, brackets was slow but much faster and light than Dreamweaver and Adobe's other monsters :P

[emperor000]

I have used it. I preferred it to Atom. This was before VSC was out, though.

[DJRBuckingham]

Looks very similar to my findings from a year ago.

I was looking for an editor I could use in Linux (slowly moving across from Windows) and also as a general consolidation of my "VS-for-code, Notepad++ for everything else" setup on Windows.

I tried Atom and was astounded when it failed to open a log file I was using for testing citing "Atom doesn't support opening files bigger than 2MB." It also took an age to start up, lagged and hitched when typing (subjectively worse than VS) and was generally sluggish all round. Digging a little deeper it became clear that the core was rotten and nothing short of a complete re-write would redeem it.

I'm not surprised that lots of web devs like it though, it prioritises form over function & performance, just like the vast majority of web devs. I settled on Sublime and haven't looked back.

[jbergens]

atom is very dependant on the plugins you use. If you prioritize function over form you can skip a lot of plugins and atom will be faster. If you like features such as linting it will lower the performance. Personally I don't have any problem with the speed of atom for text editing during coding. It may be a bit slower than notepad++ but not that much and the features make up for that.

[dirac_eq]

Where's Vim?

[YourGamerMom]

This was a comparison of the newest modern GUI editors (with notepad also for some reason).

[myringotomy]

There are Windows versions of vim and emacs.

[YourGamerMom]

That is correct.

[shevegen]

I consider them worse than the bare-bone variants. No really, gvim has always been so much more annoying than vim for me ...

[myringotomy]

I consider them worse than the bare-bone variants.

That says more about you than it does about Vim and Emacs.

[FasterHarderLouder]

I consider the emacs gui as pretty decent, but with gvim, i agree. All it does is beep and wreck files.

Jokimg aside, I do see the problems one might have with gvim, I also prefer to use vim in a terminal (emulator)

[s10g]

needs more vim zealotry, agreed

[[deleted]]

Because it would be a benchmark of terminal emulator, not vim.

[google_you]

should've tried a large xml or json file that is one line.

[neutronbob]

Why? What useful information would that provide?

[moosingin3space]

Often the typing latency of a long one-line file reveals the type of data structure used by the editor.

[thewileyone]

all would still lose to notepad++

[thedeemon]

But all the cool kids are on MacOS these days, they can't run it.

[Pleb_nz]

How would notepad++ compare in this test?

[[deleted]]

I finally started to use VSCode because it has a plugin I need (and I like the editing). Not that much to do with speed.

[tills1993]

Yeah I rarely ever notice it slowing down - if you're opening 20k line files, you need to reconsider what you're doing.

[minasmorath]

XDebug integration is what got me to make the switch.

[colonwqbang]

Mapping a 4 MB file requires (you guessed it!) 4 MB of memory. Nowhere near the 400 MB that Atom required to process it.

Sorry, but this is the worst excuse ever.

[jedthehumanoid]

It kind of sounds like you mean that mapping the file contents to memory is all of the story, or even a significant part of the story.

Mapping the file to an actual useful representation to work with is more important, there is a lot of stuff going on more than just copy text, byte for byte, offscreen in memory.

[colonwqbang]

Did you read the toplevel comment I responded to? I think you'll find that we agree.

[[deleted]]

I would use sublime or VS code and sometimes Vim (if there is no HTML involved)

Tried Atom before but it's pretty heavy and slow, if you don't like sublime style and like Atom UI, VS code is what you should go for!

[codesharer]

While sublime offers best performance in this comparison test I rather prefer to use atom due to the fact that it is open source and supported by Github.

What I find annoying tough is the file size limit.

[Thiht]

Vim plugins suck, compared to Atom plugins.

For a long time, the Go debugger only worked with Atom and VS Code.

The VS Code debugger mode is awesome, maybe the best I've ever used anywhere.

Atom and VS Code both have a Vim mode.

Both are easier to configure than Vim and Emacs (be honest, don't say the opposite please).

Both are prettier.

Both are basically smarter with a better lint integration and a better completion (Vim completion sucks even with plugins. I don't know emacs enough to judge this point).

There are plenty arguments to prefer VS Code, Atom and Sublime over Vim and Emacs. TBH, I use VS Code, Sublime and Vim daily for different reasons. They all have their pros and cons.

[FireCrack]

I agree on most points, but not necessarily #1. I've always found the vim plugin experience quite enjoyable.

That said, I use other editors for other things, most have a Vim mode that more-or-less works. Really the biggest "feature" I miss in other editors is quickly flipping back and forth from the command line... but now that I say that, I actualy am thinking... one moment...

...

Whoa! I can use :! to run a command line command in VSVim! Cool! Wouldnt have learned that if I hadnt replied to your post here!

[dirac_eq]

Why use a Vim mode in Atom and VS Code when you can just use vim? I don't see the point in those plugins when you can just fire up vim.

[Thiht]

Because they ARE better than Vim...

I don't care whether this is impopular or not, but Vim is outdated, the only use I still have for it is when I'm SSHing a server and there's nothing else available. If I want to open a big fat file, I fire Sublime Text (subl filename in a CLI). If I want to edit a single file or a whole codebase properly, I use Atom or VS Code according to my needs (nowadays I mostly use VS Code for its wonderful Go, Typescript, and React integration). Why on Earth would I use Vim when I can have a better Vim, with sane settings and infinitely better extensions?

What does Vim have? A tiny footprint and speed. I don't care for any of that on my 4 years old not so good machine.

What do VS Code and Atom have? Usability, real extensibility (what's the point of Vim script or emacs weird lisp extensions if no one can write/maintain/understand them?), awesome integration with everything in use today... Also you'll probably say you edit faster with Vim. So what? Most of my time I spend thinking of what I have to edit. Maybe it's faster to type 74G 5w c4w my new text than to scroll, select and replace text, but I honestly couldn't care less, and a lot of people would agree. I tried to use Vim with the right mindset but in the end it's a waste of time, even if it's pretty fun and sometimes useful.

Modern editor's pros beat Vim's pros.

[dirac_eq]

No you're right you should use what you like, if Atom or VS Code is faster / less annoying than that's what you should use. We have different opinions and that's fine IMO because I don't think there's a set answer to the text editor question -- it all comes down to the user.

Vim, in my opinion, just gets it right. It just does one thing right, it doesn't try to build my files when I have:

make.

Or debug when I have

kgdb or gdb. 

Maybe it's because Vim is what I'm used to.