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.
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.
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.
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++.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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 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)
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'").
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.
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.
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).
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:
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.
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
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++.
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.
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.
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.
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.
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:-)
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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").
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."
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.
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.
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 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?
255 comments
[ 3.4 ms ] story [ 281 ms ] threadWhich 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.
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).
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).
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.
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++.
Plenty of valid uses for non-text rendering, especially in the realm of plugins.
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...
>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.
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.
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.
Does it have any features which emacs — which outperforms it — lacks?
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.
[1]: https://github.com/magnars/multiple-cursors.el
And also keyboard macros, which are more often used for the use case you mention.
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'd love to see that bug fixed myself.
I hope this trend dies soon. The inmates are running the asylum.
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.)
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.
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.
How do you do this in vim? Could you give an example?
I've tried a few times to love vim but emacs keeps pulling me back.
:%s/word1\(.*\)word2$/word3\1word4/
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.
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.
If you are lucky enough to use linux on both ends, sshfa can make your life so much easier.
The development with web technologies means a big step forward in accessibility and usability and that's much more important to me.
For the rare case I do need to work on an XML with 100k lines, vim is still around and using a modern editor won't make it disappear.
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.
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.
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.
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)
There's also addon tools like vlfi if you're editing very large files on a regular basis.
I'd be more interested in ~200MB instead of 3 GB as I find myself more frequently opening log files and XML exports in the 100-500MB range.
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.
Its actually awesome - I only stopped because my wrists..
But fear not, not everyone has those issues. Mine diminish if I go to the gym...
The importance is that things like 'magit-status be instantaneously snappy to open, which currently leaves a lot to be desired.
And I also use emacsclient, which make it just instant.
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 dream of an editor with the flexibility of emacs that but the bug-freeness and speed of sublime. :)
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).
Come on emacs, other editors can handle them! :)
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:
I haven't noticed if it makes loading the files much faster (the lines aren't that long), but definitely makes it easier to read them in a terminal.https://www.gnu.org/software/emacs/manual/html_node/elisp/Pr...
https://www.emacswiki.org/emacs/EmacsNativeProfiler
Also, ESUP for profiling your startup time:
https://github.com/jschaf/esup
There's also a second profiler in Emacs, ELP, which can be used for testing individual functions:
https://www.emacswiki.org/emacs/EmacsLispProfiler
Everything else is userspace load. There's no reason why the same code on the same processor running in a straight line would perform any differently.
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.
But feature wise, it's still way ahead of Atom.
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.
TBH this benchmark is not fair for editors that have constant updates like VSCode and Atom, unless they keep up to date the results.
https://code.visualstudio.com/blogs/2017/02/08/syntax-highli...
FOSS
1000s (millions?) of plugins
RAM/hardware is cheap e.g it works fine on latest generation top of the line hardware.
No one should need files more than couple of thousand lines long.
Commit messages load up painfully slowly, however. Again, I just use a different editor, but I would love to hear any fixes for this (tried many).
I did some of these tests with Howl, here are the better numbers:
- Memory (hello.c): 22748 (RSS)
- Rehighlight test: about 3s
- Time used to load test.xml, jump to end of file and exit: 2.1s
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.
Github page for the lazy: https://github.com/howl-editor/howl
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.
Most of the editors inside of an electron shell have slow start-up and file opening times but everything else should be pretty quick.
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).
Unfortunately this doesn't measure this basic "redraw" performance.
Maximized, it's even worse - typing is very slow. But that's apparently some sort of bug.
I don't care how much memory a text editor uses so long as it does what I need.
/me waits for someone to say we shouldn't have 3GB xml files in the first place, like I don't know that already.
Is that seriously worth a >10x slow down to you?
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".
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.
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'm a Sublime user myself but I'm not blind to the appeal of other editors.
Speaking to VS Code here, I am yet to feel that '10x slow down', one bit, so yes it's absolutely worth it.
(I don't hand-edit 5.62 MB XML files often).
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).
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?
The rumors surrounding Sublime's demise have been wrong in the past, and the trend continues.
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.
I just think there is a need for more formal venues, such as a regularly updated roadmap.
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'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?
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.
If you are interested in providing feedback, the packages are at https://github.com/sublimehq/Packages. Tests could be helpful, even if failing. The test syntax is described at http://www.sublimetext.com/docs/3/syntax.html#testing and scope naming guidelines at http://www.sublimetext.com/docs/3/scope_naming.html.
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.
With atom and vscode i have lots of Devs, a big company behind it, and the source. I'm sure they will continue to exist.
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.
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.
Wow, interesting. I was aware of Qt's early history of being fully closed, but I didn't know it was in escrow like that. Link from wikipedia: https://www.kde.org/community/whatiskde/kdefreeqt_announceme...
Here's an example of another non-OSS program with source under escrow: https://fman.io/blog/transparency/#open-source-promise
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.
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.
Most of the time, the difference in performance is insignificant.
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").
I don't know the author's exact methodology, but it's possible that Atom just blew up for some tests, especially the bigger ones.
When I have to look at a large log file, I just use vim or grep with context.
You are right, but the default vim is not that great either...
For example if you use something like vim-plug[1] (amongst many plugin managers) then you can use on-demand loading to make keep start up times lean.