These tests perfectly reflect my experience of using Sublime Text. It's a workhorse that does what I want without complaint within a time frame that might not be instant but is never Too Long™. I use other editors for other tasks, but I've bought ST twice and would be happy to keep buying it.
I honestly used Atom and Code prior to deciding to try Sublime. My experience has been the same as these results. Sublime is much quicker than either one. I do still like Vim (Neovim to be specific), but right or wrong that isn't what I am comparing to Sublime. I usually just compare Sublime, Code and Atom. Of which Sublime wins by a landslide (which you can more than likely blame on Electron).
Code is not a fast editor, and you're right that this is likely linked to Electron, but I do think lumping it in with Atom is possibly turning many off it too quickly. The gap in performance between Atom and Code is phenomenal.
It's also worth remarking on that some of the treatment of these two in this article is a little odd. Atom is excluded from a lot of tests completely, and Code is particularly penalised in one test for incomplete highlighting (where it's noted it completely the functional task "quickly").
In day-to-day work, I still choose VS code over Sublime. The plugins are actively maintained and simply better. Go, eslint, tslint plugins specifically. Most of the files I edit are less than a few hundreds line of code and that's a good thing. The difference in speed for my use is not noticeable.
When I have to look at a large log file, I just use vim or grep with context.
When I thought even Sublime isn't fast enough with today's hardware tech, People are cheering Atom and Code as being very fast. There are Editor faster then Sublime, but none of them as feature rich.
I use Code for working in Javascript and have been pretty happy with it. It does code introspection better out of the box and is fast enough. But it's resource hungry enough that I can't just keep it open in the background as my "standard text editor."
I bought Sublime Text recently. I love it, but I was very disappointed to watch it become temporarily, but completely, unresponsive when opening a very large file on a network share.
I love comparisons like this. There's such a rush to get the new shiny thing, that sometimes we don't notice what we're giving up. I've been going back and forth between Atom, VS Code, and vim, for my programming for the past year, or so. I end up defaulting back to vim, for a variety of reasons. Speed is one of them (the bigger one is that nearly all of my testing happens on remote servers or headless VMs, so if I want to use an edit-test-commit cycle, which I nearly always do, vim is what I have).
There's a lot to like about the new editors, but it's a pretty big tradeoff, IMHO. Even on reasonable-sized files, I notice the speed difference, and sometimes Atom or VS Code do something pathological and end up making me wait an inordinate amount of time for it to sort itself out.
Also, Atom has improved quite a bit. It used to be remarkably slower than VS Code, and now it seems to be only marginally slower (though both are among the slowest in this bunch of tests, so it's faint praise to say Atom is "almost as fast as VS Code"). Nonetheless, Moore's law has given us a world in which even very, very, slow editors are Fast Enough(tm) for most of the work, most of the time.
Have you ever heard of sshfs? I've needed to do some work on headless computers lately and it has been a lifesaver. Basically it lets you mount a remote computer's filesystem over ssh, meaning you can edit everything in your main editor.
I'm in a similar spot but between VS Code and vi. Have you tried the vim extension for VS Code? In theory it would be an almost perfect solution but I can't seem to get it to feel natural. I might just need to dedicate more time to adjusting muscle memory.
I never try to make vim keybindings work in a GUI editor. It is inevitably an uncanny valley, where it's not quite right, and I spend more time context switching between "real vim" and "this sort of vim" than I would just doing things the way the editor was built. I have spent enough time writing prose (and even coding) in more standard GUI editor environments that it doesn't feel unnatural to work in that way. There are some things that are a little painful (I'm really comfortable with, for example, complex substitutions in vim, but not so much in other editors), but most of the time I don't need those features often enough to have it be a major impediment. Like, I have no idea how to "change these two words, but only if it's at the end of a line, and keep the words in between them the same" in any editor other than vim. I'm sure it's possible, and maybe if I ever really switch off of vim, I'll figure it out.
So...yeah, I use Atom and VS Code mostly stock, with a few plugins. I don't ask them to act like vim. I'd just be disappointed.
Over each line in the whole file, search for word 1 and word 2 (which is at the end of the file), separated by arbitrary non-newline characters, and change them to word3 and word4.
khedoros' example is correct. vim has very sed-like search and replace, so UNIX command line skills translate back and forth. It's doubly useful, to me, that whatever tricks like that I pick up can be done from scripts with little to no changes (vim has a few differences, such as being able to specify which lines to replace either by number or visually or from beginning or end of file, but the matching/replacing logic is very similar). Also, I work in Perl a lot, which also has similar conventions for searching and replacing (though it has a more powerful regex engine with somewhat better syntax, like being able to include comments and newlines), so again, it's a skill that translates reasonably well back and forth.
I don't really try to convince people that vim is better than any other thing. I get the appeal of things like Atom and VS Code and Sublime. vim was just the first really power editor I learned really well (on an Amiga, no less), and it's pretty ingrained (and I barely tap into its power...I used it pretty close to stock, and have no clue how to do tons of things without googling it), but it's very fast, for me. Heck, I don't even use hjkl cursor movement most of the time. I grew up on a keyboard with arrow keys, so that's what I reach for. I'm a sloppy vim user, but it's still more productive for me than other editors in many contexts.
It misses the : operator, which makes it impossible to do a :wq . Or rather the : operator brings up the VS code console which is completely different.
The argument people have for Atom / VSCode is that you won't notice the tiny performance improvements with small files and you don't need massive files.
Perhaps I'm just a 'sensitive' soul, but I really do notice these minor differences in performance. If there is ever a slight slow down in the editor then it takes my focus off my work and onto the editor.
I 'feel it', rather than being able to put it down into specific testable specifics.
I use ST3 mostly and I instantly notice if switching tabs is taking fractionally longer or if undos/redos or scrolling is taking longer.
The only reason I don't switch to Vim is that ST3 is much more user friendly. So it means that I have to think too much about the commands in Vim which slows down my thinking - which is the equivalent slow down of having unresponsive editors.
> So it means that I have to think too much about the commands in Vim which slows down my thinking
If you use anything long enough, you no longer think about it. Indeed, the only time I think about how I do things in Vim is when someone asks "How did you do that?" I only thought it, and it happened. Recreating it can sometimes be a short puzzle.
I'm certain this is true for other people and their editors, or anything that you use so intrinsically that it's like breathing.
Yes, I'm sure this is true. It's just that it takes a really long time to get all the commands into muscle memory. I've been using Vim for over a decade and still don't feel comfortable doing more than quick edits to individual files.
All editors from Notepad to ST / Atom, Browsers and Document editors have the same keys for search, replace, new tab, close tab, new document.
But learning vim is a completely different language. I mean that in the sense of actually learning a spoken language. Until you're fluent in it, it's really awkward.
My latest step has been finally to get round to using tabs which I'd never even really considered for Vim. But even that requires learning all the new tab commands, there's no Ctrl + Tab and Ctrl + Shift + Tab.
I'm in the Windows world which doesn't help with learning Vim as it's just not as pleasant experience as using it in the Linux command prompt.
I also think that ST3 is faster/more-responsive than vim with plugins.
For example, in order to make vim an alternativet to ST, I have to use several plugins, such as snippets, youcompleteme, etc.. Once I do that, vim has a slight delay that I just can't stand.
It's impressive how Sublime perform well despite having so many advanced features. Too bad Atom.io doesn't manage to get its performance issues in order.
Since it's based on node-webkit, that will be difficult. I find it hard to understand why they thought building text editors in a web engine was a good idea. Cross-platform support seems to trump all other considerations.
It's actually built on Electron, which is their own from-scratch version of NW. JavaScript is very fast, though, and there's really not a way of rendering arbitrary content as well as a browser.
The ability to take contributions from the community is much better, as well. Far more people can competently write JavaScript (or with Atom, coffeescript) than C++.
And when your linter wants to provide formatted feedback, or you want to render Markdown, or you want the nice code maps on the right hand side, or you want to render the MDN page for that JavaScript method you're hovering over...
Plenty of valid uses for non-text rendering, especially in the realm of plugins.
What about easy theming? Various font choices? Different languages and scripts? RTL languages? Inline images? Live updated browser tab? Tabs at all? Code folding? Minimap-like previews? Tooltips for linters, code completion, syntax errors, and more? 3d visualization? Click able hyperlinks to documentation pages? Icons for files? Etc...
IMO a browser is a perfect platform for a text editor, because you get so much shit for free, and it's done right across most major platforms.
Or you can do most of that on your own across most platforms and hope your version is faster...
Have you ever used an IDE or rich text editor? All of those features were around long before we had computers capable of running electron apps.
>What about easy theming?
That's a particular cancer that needs to die, themeing is the OS job, not the apps. You're themed electron apps look ugly and out of place on my desktop.
I never said they weren't, but their implementations have varied greatly. On the one hand you had "clearly not native" clumsy UIs and features that were very out of place and didn't support common keybindings or were very obviously the wrong type of "widgets" for the platform (I'm really glad I no longer see really shitty java file selectors that are in some crazy ass format and don't support any keybindings or even typing the path out manually)
on the other hand you had "works on windows 7 only", or "we created our own language to do this, so learn that before you contribute"
Like them or not, browsers have nailed a lot of those things, and for good reason (after all, that's all they do). They made them work well, work consistently, work cross platform, work with a great UX, and work pretty damn fast.
>That's a particular cancer that needs to die
Well this comment took a turn! Call it vain, call it stupid, call it whatever, but a good looking UI is a big point for my editor. I stare at this thing for many hours a day, I want it to look good, have a good (preferably customizable) set of colors both in the editor and in it's syntax, and I want to be able to fully customize every single part of it (I like to have my "file tree" take up the bottom half of a sidebar and the "minimap" take up the top half. I'm not going to be able to do that in sublime, in atom it's 10 lines of CSS in a config file that gets synced to all my computers I run it on).
You can say it's the "OS's job" but the OS doesn't allow that kind of customizability either. It's one of the main reasons why I and many others use an editor like Atom.
You don't need to use it or even like it, but it's not like they are doing something "wrong", it's just not for your use case. There are many people out there very happy with the workflows that atom works great with, just like how there are many others that are happy with a workflow in vim. The 2 can coexist and have different goals, features, workflows, and users without any issues. And calling a feature that you don't like a "cancer that needs to die" is silly at best. I'm sure there are many out there that see reimplementing another text renderer a pointless exercise, but that doesn't mean it's wrong in all cases.
> Call it vain, call it stupid, call it whatever, but a good looking UI is a big point for my editor. I stare at this thing for many hours a day, I want it to look good, have a good (preferably customizable) set of colors both in the editor and in it's syntax
It's vain and stupid but I agree completely, I want it to look great too. But I want my whole desktop (gnome at the moment) to look great and it does. All the apps I use regularly have a consistent theme and widget set across the whole desktop that looks great. And with a few button clicks I can change the style across every app. This kind of consistency is how apple got it's reputation, even windows was like this not to long ago. But browsers think they're special, no major browser (except maybe safari) looks native on any platform.
>on the other hand you had "works on windows 7 only", or "we created our own language to do this, so learn that before you contribute"
"Only on windows" I'm fine with that, there's nothing wrong with a piece of software being for a specific platform, I'd say the software that does is generally much higher quality, they aren't chasing the lowest common denominator. This may vary from app to app, but creating UI's is not hard, there is nothing wrong with creating 2 or 3 of them, or only one instead of 3 half assed ones.
I think it's more about letting others contribute with new features. No editor is feature complete and there is sadly a lack of easily programmable editors with good performance, good cross-platform looks and an easy and common programming language. VimScript and EmacsLisp is almost not used at all outside the editors.
You launch a popup with whatever GUI toolkit you're using, just like every other application. We had popups with progress bars before computers had GUI's at all.
I was actually pleasantly surprised by Atom's performance. It used to be remarkably slower than VS Code...like dramatically so. Now, it seems to be breathing down VS Code's neck, in terms of performance. (Both are the chubby kids huffing and puffing along at the back of the pack while being lapped by the other contenders, of course, but they're trying.)
That's interesting to hear, because I've tried Atom three times now and the biggest deal-breaker every single time has been performance.
Around the first release, there was noticeable lag as I typed. About a year later, tabbing through find results was just absurdly slow. More recently, opening a multi-megabyte JSON file with syntax highlighting was an inexcusably painful experience.
I really, really want to use and support Atom, but the performance compared to Sublime has just been atrocious (in my experience).
Oh, it's still slow. Pathologically so in some cases. But, so is VS Code. But, Atom's speed has become manageable in recent versions. I rarely find myself unable to work with a big file in Atom. For code, I rarely see files bigger than a few thousand lines (and never produce files that large myself), and Atom handles them OK (not great, but acceptable, given the other benefits of the tool). VS Code is still better, and of course, vim smokes them both. But, there are trade offs, and Atom has a lot of cool features.
I wouldn't use it for really large files, however. It really shows its ass in those cases (as the XML file test here shows).
I don't notice typing lag, anymore. Just now I opened it up and tried to get ahead of it by slamming flat hands on keyboard, but it kept up fine.
My current performance complaints are: startup time, big files (especially big files with highlighting), selecting large blocks of text (spanning more than a screen), and probably some other things I can't think of right now. Some of the plugins are buggy and prone to screwing up more than just the thing they're supposed to changing, but that's not performance-related. Just immature code that's expected of new-ish projects.
Multi cursors that allow notably powerful column editing will be the main one. For example, it might be the very best - and fun - interactive way to transform a weird CSV in a regular JS array or anything else.
It's not as well integrated and there are some rough edges, but it's incredibly useful. I use it a lot. Often for quick local refactoring, but also for larger things like you mentioned.
In general, editing large files in Emacs is super-fast.
What's NOT super-fast is editing files with super-long lines (it doesn't even have to be a "big" file). For whatever technical reason, that can grind Emacs to a halt.
I am a huge emacs fan, but there is a reason I still use vi/vim, and gasp, even nano regularly. It's on just about everything and is quick and simple.
Also, at first I wondered why vi wasn't on there, but for those of you who thought the same, nvi is berkely vi (TIL).
I like that emacs performs in the middle of the road in most of these cases, because it shows stability but room for improvement. Dissapointed with the large file results, but they are useful. (using vi on big files from now, it's a problem I run into more and more)
Emacs is much worse with long lines than it is with large files, and the test here uses 1,000 char lines. I'm not even sure I'd dare open a file that consisted of merely a single one of those.
However I've had no difficulty using it to view 3GByte files with 80-column lines. I don't have one handy to try but I did quickly load a 450MByte text file (6m lines, most 76 chars) and it took about 3 seconds to load.
I haven't had any problems loading multiple gigabyte log files, either. For really big files, there's even an Elisp "hack" to make it work better: https://www.emacswiki.org/emacs/vlf.el
I also have the following function in my .zshrc to disable "word wrap", specifically for when I need to read large log files that may have very long lines:
yeah, emacs long line performance is in a really sad state. i find it can be quite handy to output really long lines in log files ("hey, here's all the game state at at tick N"), which i end up having to view either with command line tools or in sublime :-/.
i dream of an editor with the flexibility of emacs that but the bug-freeness and speed of sublime. :)
What I've typically done: output things as groups of lines, separated by blank lines, then use C-<up> (backward-paragraph) and C-<down> (forward-paragraph) to move between the blank lines.
Also an option: C-x [ (backward-page) and C-x ] (forward-page) to move between occurrences of ^L (ASCII 12 - you can enter it in a buffer with C-q C-l).
For what it's worth, the real scourge with emacs seems to be people's bloaty config files. I have a fairly small .emacs with maybe five packages to load, takes about 1.2 seconds to open (and finish displaying) on my mac, about .2 seconds on my linux workstation. The editor itself actually starts up much quicker, about 110ms on my mac, 40ms on my workstation. Also, generally I use emacs daemon, so I don't really need to start it up at any point.
I don't tend to open files in excess of 100MiB, or do more than about 20k replaces in a file interactively, so I never really notice latency on operations.
I don't care how long my Emacs takes to boot up (currently probably a whole bunch of wall-clock seconds what with all my config files being tangled from Org mode or whatever), since i only start it once every few days or even weeks (when i reboot the kernel, haha i mean host computer, usually).
The importance is that things like 'magit-status be instantaneously snappy to open, which currently leaves a lot to be desired.
Slow emacs start times are very solvable with some smart lisping. Basically, don't '(require)' anything directly, instead make it load lazily when you invoke a particular mode. So set up lots of hooks. Moving your settings into the Customize system lets you do a lot of this for free. After I converted my 10+ year old .emacs into customize and lazy hooks it sped up from roughly 8 to 10 seconds to under a second.
And I also use emacsclient, which make it just instant.
Not that different; Emacs without complex ~/.emacs.d/init.el loads quite quickly (in unscientific testing on my dev VM with a cold cache, 214ms for "emacs -nw -Q -e 'kill-emacs'").
Just jumping on the Emacs bandwagon here to Ask HN: does anyone have tips and tricks for profiling my real-world Emacs setup? Between perhaps a too-large .git repository, and all my loaded extensions, and perhaps spellchecking or font-lock, i'm sometimes not sure what's causing latency, and while i couldn't go back to Vim feature-wise, i do miss its speed.
This benchmarking may seem silly on a surface level, but when you are working in a large codebase like the Linux kernel or the Android open source project, the low speed of editors like atom is crippling to productivity.
Which is very unfortunate as atom is a rather nice editor from most other points of views.
That being said I've yet to find a good IDE even that holds up to being used in a workspace with the kernel and AOSP.
Hell, when I open up common javascript libraries (which should be the most closest thing to native considering that Atom is an electron app) I often have issues.
about year ago I was working in the illumos kernel codebase and was using sublime. It seemed to work well enough for what I was using it for, still was a bit hard to find the appropriate file quick enough though.
This comparison totally misses the the normal workflow for Emacs.
Nobody normally starts an Emacs instance to edit a file and quits it afterwards. Typically you run Emacs in server mode, and use emacsclient to instantly open whatever files you need.
By the same token, somebody could give low marks to IntelliJ or Eclipse because it may take a good 20-30 seconds for them to load.
It also missed the mark with many of the others on that list.
The line between editor and IDE is getting more blurred every day.
I use Atom. It gets opened once a day and closed at the end of the day. It could take minutes to start for all I care. The amount of time saved by having the vast set of plugins, the customization, the tools, and more greatly exceed any kind of savings I'd get from faster startup time. People tell me how I'm wrong because my editor shouldn't use so much memory, I try to tell them that I'm more than happy with the memory usage for what I get and it runs fantastically on my computer.
But at the same time, I use nano on remote machines for quick edits all the time. If it were slow to start, it'd be useless.
And again if I were using an older PC with 4gb of ram and a 5400RPM HDD I might feel that the performance of atom is an issue, so I'd probably use something else.
I'm glad there are so many options that all focus on different workflows and features. Just because one doesn't focus on the workflow you use doesn't make it wrong or worse, just worse for you.
They are open source, much easier to extend than Sublime, and, most importantly, are regularly updated. Sublime goes through droughts where its creator is AWOL and when I used it I regularly wondered if each update was the last.
Indeed. Sublime is amazing but just look at the last update which came out in September 2016 and mentioned getting things in order for a v3 final release soon. That was 6 months ago now.
It might be true for you, but it doesn't look like it from the outside. It's fine if the editor would cost $10, but you're asking users to pay up $70 for a product that looks dead, and it's not even a perpetual license. It's just for the "current" version, whatever that is at the moment (I'm using Sublime Text 3 but it's still in "beta" since years).
I think Sublime Text would benefit from you and Jon being more active in communicating what's going on and what's on the road map. Perhaps someone else could help you, but the information still has to leave the silo of the core team.
You said it appears Sublime Text is dead. My point is that if you look at places where we post things other than release announcements you'll see all sorts of conversations going on that development is continuing.
Jon has never published a roadmap. If you think Sublime Text is dead because it doesn't have a public roadmap, then I'm not sure how to convince you otherwise. I mean, we did over 20 releases in 2016, with over 50k lines of syntax definitions and tests published on GitHub.
By the way, if you are a Sublime Text user, I'd love to get some feedback and bug reports on our Erlang syntax! We don't seem to have many Erlang users, but I'm sure the syntax could use some improvements.
I guess what I mean is that if you look at the the public page, Sublime Text 3 haven't had a release in half a year, and digging into the forums to discover if the project is alive is not what what everyone will do. I also don't think it's clear who's on the team for outside people.
I've thought about contributing to the Erlang syntax a couple of times. Is a rewrite in the new syntax format of any interest or do you want to keep compatibility with TextMate still?
Thanks for the feedback! I'll talk to Jon about trying to make the website push people to the forum to see what is going on.
We no longer keep compatibility with TextMate in any of the default syntaxes. Everything is now a .sublime-syntax, and has access to all of the advanced stack and scope manipulation features.
> Is that seriously worth a >10x slow down to you?
Mostly working with reasonably sized files, there's almost never a perceptible delay in anything except initial startup. A 10× speedup in the editor (which isn't the limiting factor) would have basically no value, so it's not worth compromising anything to get it.
That said, there are things I prefer, e.g., full IDEs or more specialized editors for, but almost never is it because Code or Atom is too slow.
Atom is free, sublime is $70. That counts for a lot.
The number of extensions for atom is vast (and there are some really good ones), and installing them is much simpler.
I use sublime & atom both at home (OS X) and at work (Windows) and atom is much closer in terms of performance on my home machine. I think the faster SSD & lack of anti-virus crud count for a lot in terms of how fast atom can open files which for me is the most noticeable performance difference.
To add to this, if you are hobbyist that writes small programs that don't have huge numbers of lines of code, then then slowness isn't really a dealbreaker for you. I use Atom myself for python/django programs. My sister who is in school right now uses IDLE for all her neuro-linguistics based programming. I mean, if your needs aren't that big and your focus isn't the code, you don't really need a fancy editor like sublime.
$70 for a tool you use multiple hours per day is nothing. If you're just a hobbyist or a student I guess I could understand the hesitation but for a professional tool that is dirt cheap.
In sublime for installing a package I do this: Ctrl+shift+P, type 'inpa' Enter (selects install package), type first letters of name of package (emmet for example), hit enter.
I don't even need to use the mouse. I fail to see how the Atom method is 'much' simpler.
Have you used other editors much? I use Sublime Text as my daily driver, and often pull in VS code for some specific features. It feels so incredibly sluggish by comparison.
Yep, I used Sublime for a while, and I'm a Vim user as primary editor for the last 6 years.
Planning on switching to VS Code full-time as soon as I can figure out how to add a couple of simple bindings to (custom) things I have setup in Vim.
It's snappy as hell for me, on a mid-range Mac Mini. Really impressed with the Vim mode, which includes things like tab support which other projects (like SpaceMacs) don't.
Granted startup time takes about 10 seconds, but then my iTerm startup time is pretty similar on this machine, so that doesn't bother me. Once my editor is open I'm going to leave it open all day (and ditch my Vim habits of perpetual ctrl-z/fg).
The best thing for me has been that VS code has a sane php debugger (PHP has a truly awful debugging experience in general, though that's in line with the rest of the language ;) ). Sublime's PHP debugging addons are not good.
I think my biggest VS Code complaint right now is it seems to hide tabs away once I have like 3-5 open. Is there a way to get it to shrink tabs (like browsers/sublime) to have them all open and visible?
I would accept the slowdown simply because sublime is not open source. On most my machines non-open source software for which I cannot readily access the source gets run by a different user at a minumum, often entirely isolated in a VM.
I started working with Jon in Jan 2016, and we did over 20 releases in 2016. You can check out my activity on the forum and the packages repo on GitHub to see some of the public activity. I also tend to hang out on IRC and the Discord server.
Sublime Text has now existed as publicly available for nine years now. In general I think the track record for continued development and improvements is fairly evident if you look.
Sorry, i didn't know the whole details. But, if Jon decided he wanted to "take his ball away" tomorrow, could you or anyone else make a new release?
Don't get me wrong, sublime is a great piece of software. I wish it had, like QT used to, the source in escrow, to be released under GPL or BSD if a nominated independent person decides the software is ever "abandoned". I've been burnt once too often by abandoned software.
The benchmark talks about "load time" and "jump to the end"
in practice you only need to do that once, and the editor is only rendering the current visible portion of the code. So the relative slow down is more than acceptable. Plus the experience is just so much richer. Sure some editor is quick to do things, but with richer APIs / functionality, developer's time saved is way more important than the several milliseconds of machine time saved.
Unless you are using a pretty crippled computer to work on, then yes, you may not need VSCode/Atom. Otherwise I don't see an issue here. everything is about choice.
These benchmarks on a modern i3/i5 processors and with 8GB of ram, which is almost the standard now, wont give those slow numbers published.
also, I'm pretty sure VSCode at least have gained way more performance that you wouldn't notice these "lags".
>These benchmarks on a modern i3/i5 processors and with 8GB of ram, which is almost the standard now, wont give those slow numbers published.
I don't think that's true at all. My personal experience using both VSCode and Atom on my i7-6700k/16GB work machine has mirrored these results. Files over 30-40k lines simply crash the program.
Maybe sending those crash reports might help you to get them fixed, pretty sure next release (early April) would get fixed. Or if you use insiders build, could get fixed sooner.
I run Slack all day, signed into and switching among 4 accounts. Plus Apple's Messages. Plus chrome and safari, each with at least 6 windows open and dozens of tabs among them. And I then have at least 2 instances of VSCode open, each with dozens of tabs. I never experience the slightest perceptible speed or performance problem.
This is on a late 2015 MBP with 16GB RAM. On my prior machine, with the same daily behavior, I still never experienced performance problems in VSCode.
I used to use ST2 & ST3. Bought both. I just don't find a compelling case for it given the huge and active extension community for VSCode.
Slack, however, frequently has performance problems.
I also don't open files regularly that exceed 4-digit line counts.
I wonder how Acme[0][1], developed by Rob Pike for Plan 9 would compare. It feels fast and light, but I only ever use it for files lighter than a megabyte.
It opens a ~190 MB JSON file[0] in about 2 seconds on my machine. Scrolling and jumping around the file feels very smooth. Editing is also crisp. Writing the file back to disk takes about as long as opening it.
For test.xml the RSS is 20MB and opening it and going to the last character is instantaneous, search and replace on test.xml takes slightly less than one second.
I've been using Atom for the past several months. I was using Sublime Text 3 before.
This confirms my observations that Atom is both significantly slower and also consumes more resources. I mean, the numbers speak for themselves: It uses at least an order of magnitude more RAM compared to most of the others, and common tasks are up to two orders of magnitude slower.
At first I thought the issue was my old laptop. But now I see the benchmarks, I'm definitely switching back to ST3.
Is this really a surprise though? It uses Electron, which loads an entire web browser just to do text editing and adds several layers of indirection which aren't needed by other editors like sublime.
My two cents; there's a ton of space for productivity improvement in editors. Projects that allow more and newer features is what I'm interested in.
I don't like the fact that Atom and VSCode are slow and memory hogs. I do like that fact they are running in a cross platform environment with access to canvas, webgl, svg, images, video, networking and more. I want to see where that integration leads. Whether it's inline diagrams or code flow diagrams in a separate pane or ???
I also like the idea that editors could be written to be more friendly to plugins and customization than previous editors. I get that emacs and vim can be customized but there is arguably room for improvement. Whether it's easier APIs, an in editor plugin browser/installer, or things like Microsoft's external code meta data protocol that potentially let's more editors share support for more languages.
Of course I want speed and I have not switched to either Atom or VScode yet but both seem like a step forward where as emacs, vim, and even sublime feel stuck in a previous generation of design
> I get that emacs and vim can be customized but there is arguably room for improvement.
There is, of course, always room for improvement, but I think you are selling Emacs short here. Emacs is roughly 85% lisp, which is what you write to extend it. Not only do you have access to everything the core parts of the editor have access to, you can jump to the source of any editor function to see how it works. Since most of it is written in Lisp, you can assume that it has been dogfooded to death. Lisp is very much a first class citizen. And practically every public function is documented, and that documentation is just a keystroke away (C-h f).
When you launch Emacs with no filename it even dumps you into the "scratch" buffer, which is really just a lisp repl. Everything about Emacs is geared toward not just customization, but full on extensibility.
Emacs also now has all the stuff you'd expect—browsing, downloading, upgrading extensions (called "packages"). It also supports customizing the editor without writing any lisp code (M-x customize-*) if you don't want to be forced to learn lisp right away.
Emacs still has quite a lot of energy, people are working on deep levels (core, guilemacs) and the community is handling the userspace part through packages (melpa, etc). There are a few warts in a way compared to the layouting flexibilty of html/css, but beside that, the ability of emacs[-lisp] to absorb any new idea is still very high. Long time ago, when Sublime grabbed a share of the market, there was a 2 hour long video about what ST brought you. I yawned all along. The few things that weren't already in emacs appeared organically in no time; whereas 70% of features were there since the 90s.
My view is biased, I'm in a lexicalist period (blame it on sml) where I want a few equations, type constraints etc and no visual flexibility (which I wanted in the past).
His point wasn't that Emacs has fewer features, his point was that many of those features are half-baked compared to the implementation provided by Sublime.
You give up a bit of flexibility for more stability and overall polish.
That's almost true; surely the flexibility makes the system a little less "solid" in appearance. Just like a bare unix shell looks like frail compared to a full fledged GUI application. But for those who likes depth, it's not fragile or half baked, it's decoupled.
No Geany ? I love this editor. It's supports most languages(syntax) has some default compile-hotkeys for most languages.. Doesn't feel as clunky-slow as full-IDE's
CTRL + F'd to see if anyone else had mentioned Geany. The fact that it is cross platform as well as having great performance made it my go to. I use it on my underpowered Lubuntu laptop and my beefy Win i7 workstation.
Except that Notepad++ is running in wine - which much as I think wine is awesome is not perfect. You don't know if a pathological case (e.g. the result for Rehighlight test) is Notepad++ or wine.
In general yes. I did mention that I think wine is awesome. But it has bugs and the windows APIs it translates are tricky. I assume that the behavior in the re-highlight test is due to a bug. We don't know if this is due to bug in wine or a bug in notepad++.
I'd like to see Kate added. It's one of the most capable editors on desktop Linux and bundled by default on many distros. Curious how it performs in direct comparison!
One thing missing from the test is what options are being used in vim. I would like to see "vim -u NONE" added, which basically acts like pure vi. Yes, vim cannot really handle a 3GB xml file with syntax highlighting, but if you use "vim -u NONE" it is not a problem.
Or a few other cases of large files, e.g. huge c files (like the sqlite3 amalgamation). Vim's xml syntax highlighting in particular is very slow, but other C-like languages are fine.
I find Lua much more pleasant than Lisp. It is also performs significantly better. This could result in a very nice editor if enough people embrace it.
Solidifies how I felt about Atom. I'm unsure how people use it regularly. I found everything extremely slow. It's a pretty editor, but the speed of it is a killer.
For editing text, everything these days should be considered a high power computer. When a text editor is unusable on a computer that is at least 10,000x as fast as old computers that could edit text just fine, it is time to take a giant step back.
I would be interested in seeing vim, nvim, and emacs performance using a slew of plugins to get to the point where their functionality is close to the features that sublime/atom/vscode have out of the box.
Emacs has many of those out of the box, you just need to tweak/enable them. The worst thing about Emacs is it's default settings, because the whole point of it's existence is customization to very niche and personal needs.
Same. I'm not really sure what it is, but the moment you add a few plugins to vim, you definitely notice a slowdown. I'm sure it's the abomination that vimL is.
I do use plug, actually. It was more a complain to the fact that the editor does feel a bit sluggish sometimes if you have a few plugins on. I think vimL is a pretty darn slow language (not to say that it's probably one of the worst languages I've ever touched).
I wouldn't, because none of that functionality is/should be involved in the simple tasks that were benchmarked in the article. If it still slows down these things by orders of magnitude, it has to be implemented sloppily, don't you think?
UltraEdit is an old but VERY fast editor with a crazy mount of features like diff and a hex editor. I sadly had to stop using it because their licensing is too restrictive (can't use windows license on linux; can't move windows license to another computer; online activation which only works x times and then you have to write to support ...).
My experience has been the exact opposite. The latest version of UltraEdit easily handles large files that Notepad++ and Sublime Text 2 choke on. Didn't purchase Sublime Text 3 yet so the situation might be different there.
I notice they don't include IntelliJ. I know it's not normally considered an editor, but it's worth noting just how much faster it is than other editors in this latency test.
https://pavelfatin.com/typing-with-pleasure/
Only faster with `editor.zero.latency.typing=true`, which I don't think is default. Othersise, IDEA has some of the highest latency in the tables I saw on that page. On windows worse that Eclipse, on Linux worse than Atom even.
IntelliJ is my daily driver, but god it's slow for me. I can't figure it out. It's OK, on my laptop, but when I plugin an external display it's performance tanks.
The big problem vim has in this particular test case is the XML. Vim syntax highlighting of XML is significantly slower than other syntaxes. I disable it for XML in my vimrc.
A large C or json file would be a good test case to add.
(Also, as someone else mentioned, the 3GB file also had rather long lines, some of these editors that failed on that file can handle 3GB files with ~100 character lines.)
Whenever I sit down to help someone on the team that uses Atom, I am always frustrated with the performance of Atom, even compared to Sublime Text. Granted, I am always cognizant and sensitive of these small differences, but it feels as unacceptable as working on a laggy, malware infected computer.
Not sure what kind of computers you're using. Atom has a slower than most start-up speed and occasionally file opening speed but beyond that it's very fast without lag / latency.
Most of the editors inside of an electron shell have slow start-up and file opening times but everything else should be pretty quick.
Isn't that the point of an editor? That I don't have to use a bulky machine just to run it. If I have to run a machine with 16GB of ram to run the editor I am better of just running a full fledged IDE.
I'm not sure I follow. You don't need a "bulky machine" to run a web application inside of an electron shell. They're pretty quick. Sure they use more memory and have a slower start-up time but it's not that bad. I run VSCode on a base level MacBook Air from at least 5 years ago (I think it was the 2nd generation?). My previous PC laptop that was about 8 years old also ran VSCode fine.
My point is that some aspects of it, typically ones you do once or a small amount of times, are the points in which it is slow. The performance after those points isn't bad and I've never seen laggy or sluggish scrolling or text input (or at least I hadn't noticed it).
I tried to rerun some of the benchmarks where vscode claimed to be so bad, Couldn't reproduce it, for instance, the replace with regular expression and inserting the "'<!--'" , those were < 1s or almost instantly. I used latest version of VSCode tho.
TBH this benchmark is not fair for editors that have constant updates like VSCode and Atom, unless they keep up to date the results.
Atom has memory balloon when loading test.xml without highlighting, takes 4x as long as Code to rehighlight, simple search and replace basically doesn't terminate.
They are both terrible but at least Code doesn't seem to hit any degenerate cases.
People said that about Emacs, too (Eight Megs and Constantly Swapping!). And in 10 years, when hardware has finally caught up to the point that atom (A Terabyte of Memory?) has almost acceptable performance, it will be all but abandoned in favor of an even slower and more resource intensive text editor.
This sounds reasonable. 2 decades back if I had known my present annual salary I would have imagined that money is perhaps enough for lifetime but now I know better:-)
Wow didn't know that Sublime is faster than vim ( some cases ). I'm always surprised by how sublime handles big files, but would've never imagined that it's faster than vim.
It would be interesting to know if word wrap is turned on or off. This makes a humongous difference in some editors, especially notepad++. Turn it off and you can easily open 1GB files, turn it on and it will crash on the same file.
To make the comparisons fair, the table should also include whether the editor highlights (and indexes) the file using a proper parser instead of just line-by-line regex.
More realistic hardware would also be interesting. He doesn't even have SSD...
I was trying a bunch of different editors last year and tried Atom out. I have used it ever since. It just seems nice to use.
I am not really seeing the performance issues others are. I use it on a 1st generation i5 laptop with 4GB ram on Ubuntu, and in an Ubuntu VM on Windows 7, so I'm doing alright on low end hardware.
When I have to open very large files, it is usually log files on a server and I tend to us grep and tail etc...
Honestly for editors like Code or Atom, working with large files or huge XML is more of a niche feature. What I care about in editor performance is responsiveness, entering characters and having them show up correctly colored on the display. Or navigating with keyboard shortcuts.
Unfortunately this doesn't measure this basic "redraw" performance.
VSCode on an Xubuntu 16 VM (VMWare Workstation on Windows 8.1) on a 5th gen i5 with lots of RAM seems very slow to draw. Even the menus are visibly slow. I was disappointed as I thought this might be a quick and easy way to get vim bindings + Rust editing.
Maximized, it's even worse - typing is very slow. But that's apparently some sort of bug.
same, I'm happy to have multiple editors available for different tasks, use code to code a bunch of things, I'd start worrying if I had HUGE files. big files I rarely need to open in an editor, often I just need to extract something out, in which case I use grep.
This is great and all, but I'd really prefer an updated benchmark on things I do on a minute to minute basis (e.g., time for a keypress to insert a character, time for tabs to switch, etc.) Large file benchmarks are nice, but usually I'm in a sub 1000 line file and it matters more how fast input is across the board.
A year ago, people made fun about how programs will get proportionally slower once all the developers have switched to SSDs. Now we're already talking about having to upgrade to NVMe disks for a decent code editing experience.
Take those numbers with reserve. If anything they are 8 months old, RSS is 56 MB for hello.c on my installation of VS Code. I can run VS Code comfortably in VirtualBox on a midrange i5.
Edit: Also moving around test.xml doesn't take 22 seconds, it's pretty much instantaneous, although replace is still slow.
I once had a friend who closed all apps he wasn't using at the time so his memory usage was always below 40%. I told him this was ridiculous to purchase a computer he was only using so little off.
I don't care how much memory a text editor uses so long as it does what I need.
For the same reasons I like editors that use less RAM. I leave all kinds of stuff open all the time because that's more convenient, meaning eventually I run out of RAM no matter how much I have. If an editor takes a gigabyte of ram, that means it's one of the first things I'll close because it's the largest gain. If instead the same editor would only use 100mb of ram, it could stay open indefinitely and I would close a few browser tabs instead.
I can understand leaving some background processes, but why leave open apps you aren't using? It's a bad habit. It's not just memory but also CPU cycles and battery life. Take my mother's iPhone 6; her phone runs slow much of the time because she doesn't care to close out apps she's not using. When I take her phone there's probably 20 apps running eating away battery life and performance.
This is not how iOS works. Only few apps work ("eat away battery life and performance") in the background, and only in some special circumstances (active music playback, background refresh once in a while if user allows for it). The apps seen it app switcher (double home press) are effectively dead, their state is kept around to allow user to switch back, but they cannot do any processing in background.
I haven't noticed any effect on battery usage or performance from closing iOS apps. The OS seems to manage that just fine on its own. I have completely stopped closing apps.
VS Code seems extremely responsive to me when in use, but fairly slow to start and exit. I wonder if this makes VS Code look worse than it is in those benchmarks.
What I would be interested in would be time from keystroke to screen, scrolling, etc.
This is about what I would expect. I generally develop using sublime. When things get hairy, or on the server, I switch to vim. For the big files, you have to bust out the unix tools to do the heavy lifting.
As a heavy user of Atom I am surprised with the benchmarks. To me the editor is fast enough, can't provide any numbers but it is pretty responsive for daily usage (Python, C, Puppet, Elixir, Erlang)
I don't use Atom at work because of speed issues - working on a codebase of ~250k lines and it takes quite a while to search/replace, and fuzzy match on file opening. I do use it on personal projects which are much smaller though.
Does the time to open that 3GB file include saving the file? If so, EmEditor (https://www.emeditor.com/ windows only, payware) is way faster (my unscientific test via stopwatch gave me around 3 seconds) ;) It also supports only opening parts of a file (so limiting it to the first 80 kbytes takes the time town to some ms).
Sorry if I sound like a shill, but no one seems to know of it and I simply love it's speed.
I am slowly preparing comparison on basis of real edits. I want to get most edited files from Linux kernel and prepare edit commands based on diffs. Then run those edit commands on few editors, compare the speed of whole operation and resources usage. But most important thing is how quick is navigating through whole file at random after all edits.
Editors using ropes should have fast edits, but may have slow navigation after lots of edits.
It's not clear exactly how this was generated, but emacs ships with a full-featured XML editor as the default XML mode (https://www.emacswiki.org/emacs/NxmlMode) that includes syntax and schema validation, which probably impact the XML benchmarks.
Sorry, late to this party, but Gentoo/Funtoo Linux. Funtoo has git-based portage, simple to install, up and running quickly. Yes, there are still compile times to deal with, but with fast machines these are pretty minimal. I find Funtoo/Gentoo the only distribution I can maintain long term.
I like atom just because of the easy plugin management. But it is slow as hell. Would love to use vim or emacs, but I don't want to invest too much time into learning one system. Would want to learn the better one. Too bad notepad++ only runs under wine.
When I read the title, I thought this would be about the time it took to write a piece of code in each editor. Yes Visual studio has a ton of overhead, but I doubt I would write code faster using nano...
While nice to know... I'd still prefer VS Code for my day to day usage... even at ~400mb of ram used. The workflow is just nicer, and for most files I would ever touch (well under 100kb), not a big issue.
If I ever need something larger than that, odds are I'm using an editor geared towards larger files... different experience for different situations.
vscode works very very well for doing what it was intended for. I love using it for web and golang projects. If my work required me to edit 3GB files however I would use something else, probably not a generic text editor.
Features are intended to save time, right? So...is an infinitely featureful editor best, if it also takes infinite time to complete operations? I know this is an absurd extremity; just trying to make a point that features that end up taking longer to "do the thing" than a faster editor with fewer features could do the same thing, aren't providing greater utility than the less featured editor.
Note, I'm not saying that the more featureful editors aren't worth the trade off in performance. Just that there is a point where it wouldn't be a good trade. I use both Atom and VS Code (trying to figure out which I like better) for my more complex projects (a lot of files/deps/etc) that I can test locally. But, fall back to vim for quick changes on single files and whenever I'm testing-editing-committing on a remote machine or VM. It's a feature that vim starts instantly, wherever I am. It's a feature that it's still fast(ish) even over a slow(ish) network. A killer features in this case...I can't use Atom or VS Code, at all, on a remote server over a slow link. Literally impossible to do.
So, why not compare a bunch of different editors with wildly different capabilities, if it provides insight into the relative performance and sizes of the editors? And, to be fair, some of the fast/light editors are roughly as capable as VS Code, Atom, or Sublime. vim and Emacs are plenty powerful editors with huge ecosystems of additional functionality. I understand the appeal of a good GUI, and the bigger/slower editors do have superior UI to vim or emacs, but it's just one feature of many we can compare.
Would you say it's fair to compare the memory usage / loading time of a huge TS file in VSCode vs in vanilla Vim, when one loads Language Services and provide advanced language features while the other just does Syntax Highlighting?
Or comparing Vim against Sublime for loading large files, when Sublime needs to draw the very fine and useful minimap but Vim doesn't?
In addition, most of these perf tests are extreme cases, whereas some editors are optimizing for more common use cases.
I dunno what "Languages Services" is. I guess I don't need it?
It doesn't have to be fair to be useful and interesting. Software doesn't have feelings, so we can judge it on all sorts of metrics, fair and otherwise, without causing harm. Performance is a feature I value. So are some of the other things the bigger slower editors do. Having real metrics about their relative differences is useful, IMHO.
I looked into text editors for handing very large files several years ago. For your perusal my results, hopefully not too outdated: [0]
.
SOME USEFUL SPECS to consider
* Performs with %yourmemorycapacity% and %yourdiskthroughput%
* Optionally disable features that multiply required memory capacity and disk capacity & throughput: Auto-backup, temp files, auto-conversion to different character encodings (e.g., 8-bit to 16-bit)
* Optionally disable parsing of data (for any purpose, from syntax highlighting to structured data)
* EmEditor: This was very impressive. The speed is breathtaking for what it does, and it can handle advanced functions such as column operations on the full file with ease. We chose this and users were very happy; it transformed their abilty to work with large text files.
----
These were on our shortlist to test next but we didn't get to them due to available time and EmEditor's fantastic results:
* VEDIT: Designed for large files. They charge for it, IIRC, but based on its reputation it is worth the investment.
* The Semware Editor (TSE): Also a great reputation
Time spent thinking about code and typing it in, one letter at a time: thousands and thousands of hours. Editor performance is never something I've worried about.
