8 ms·

Why I Still Use Vim

168 points by johnsnow0 9y ago

jdrzj 9y ago
I use both vim and atom, but I can't imagine writing code all the time in vim.
dspillett 9y ago
How much of that is fixed cost? i.e. how much of that 1Gb is still consumed if you have no file (or a single empty file) open and how much is consumed when you open a second 6MB file?
- Marazan 9y ago
  It took 256 Meg to open a 60 byte file. So we can probably assume that is the floor.
  - monsieurbanana 9y ago
    Was it the first file open? Or the first of it's kind? I doubt atom will use 2.5 gb to open ten 60 byte files.
- nothrabannosir 9y ago
  That's the first point of the article. Well before the titular 6MB file.
  - dspillett 9y ago
    Ah, I skipped the article assuming from the post title here it would be the usual overly breathy "look at this one number, aren't I clever for thinking it silly". I see the title here has been improved. I would suggest something more meaningful but not much longer though, something like "Why I Still Use Vim: memory Use By Code Editors".
kristopolous 9y ago
A good thing to learn is gnu ed. You can navigate around, replace text, append, prepend and delete lines on a 1GB file using a few KB of memory.
- sovok 9y ago
  It's the standard editor after all https://www.gnu.org/fun/jokes/ed-msg.html https://www.gnu.org/fun/jokes/ed-msg.html
Klathmon 9y ago
These kinds of comparisons always seemed a bit silly to me. It's like complaining that opening a 6MB file in windows took over 3GB on my system! (ignoring that most of that is the OS getting ready to do other things, and enabling the OS to do things other than opening and reading a 6MB file). Yes, Atom isn't the most resource friendly editor out there, and nobody is claiming it is. But it is one of the more capable editors out there. That 1GB allows for things like easy theming, inline image viewing, styling/theming via CSS, plugins/extensions written in a web language (which many of it's target demographic use), complete freedom for plugins to do almost anything and everything, a full web browser for easily rendering markdown/websites-in-progress/documentation/etc, code linting, compiling, debugging, decompiling, etc... Not to mention that a 6MB file is pretty fucking big for something like atom. Yes, I know, 6MB isn't "big", but for an editor which is designed to only work on source files which are AT MOST a MB, it's big. If all you are going to do is open a 6MB file with none of that, then stop using it, and stop acting like it's bad software because it doesn't cater to your needs. Vim won't show me 4 panes with ES2016 in one, the compiled version in scrolling-lockstep with the ES2016 pane in the next, and a visual preview of the page as it currently is in the 3rd, and the documentation to a function i'm working on in the 4th. That still doesn't mean it's bad software, just that it's not a good fit when compared to the alternatives for me. Stop complaining that the hammer is better than the screwdriver because it can hammer in nails better.
- konart 9y ago
  >which many of it's target demographic use So true, I almost posted a joke as a comment, only to delete it before actually commmiting a crime. >Vim won't show me 4 panes with ES2016 in one... I'm pretty sure most of this is doable though (not a Vim user)
  - deleted 9y ago
    [deleted]
  - zacmps 9y ago
    It can do all but the third. Vim's understandably limited to displaying fixed size characters and so can't render webpages. Hoover projects like Oni, Nyaovim or gonvim (All built on neovim) have the potential to change this (If they haven't already).
molestrangler 9y ago
I gave up on Atom when I found MS Visual Code, for this very reason.
- tracker1 9y ago
  To be fair, up until the latest VS Code release, it didn't do very well with larger files either... much better since 1.15, but I rarely have to look at a file that big.
deleted 9y ago
[deleted]
OrangeTux 9y ago
Nothing new, right? A lot of Electron based apps use lots of memory.
mugsie 9y ago
The other takeaway from this is that if (like me) you prefer a GUI / X style editor, sublime text is a pretty good contender. Personally, I really like Sublime, it was one of the best returns on investment for me (even buying it twice).
algoexpt 9y ago
Or use sublime text. Seems to fare well.
dingari 9y ago
What I take from this is to continue using Sublime...
tombh 9y ago
> I’ve primarily stuck with [vim] because it’s an extensible editor that doesn’t hog all the resources and kill my machines. Exactly, BUT ... Vim has a non-mainstream shortcut interface, which I've always thought is an unfortunate caveat. So over the years I've actually managed to massage Vim into behaving like a 'normal' editor. It fits into a plugin if you're interested: https://github.com/tombh/novim-mode https://github.com/tombh/novim-mode
- annabellish 9y ago
  But then what's... the point? That vim has a rich and expressive language for text navigation and manipulation is the only thing that sets it apart from more modern competitors.
  - tombh 9y ago
    That was the part of the sentiment of the quote - the point is that Vim is notable for 2 distinct, but unfortunately inseparable, reasons; 1. Modal editing. 2. One of the most ubiquitous, lightweight, stable and extensible editors in existence. I just want there to be at least a semblance of a possibility to separate these 2 things.
    - jimktrains2 9y ago
      Have you tried emacs?
      - tombh 9y ago
        Yes, but it doesn't exactly have 'conventional' shortcuts either, right? It's a little more heavyweight over Vim as well. So in the light-but-powerful editor universe, I think Vim just pips it to the post. Which is why I use it, albeit with 'normal' shortcuts.
        jimktrains2 9y ago
        Depends on what you mean by conventional. It's the default key binding style in most terminals.
rangibaby 9y ago
I actually care more about power usage than anything else these days. If it takes 1GB of memory to do that then so be it; that's cool (literally) /EDIT this comment refers to the general case not Atom in particular
- eivarv 9y ago
  Aren't Electron apps such as Atom known to have a significant impact on battery life/power usage?
samdoidge 9y ago
I've tried Atom - quickly went back to Sublime from my speed tests. I had a similar speed issues with https://hyper.is https://hyper.is vs iTerm. These new tools look pretty but performance matters, especially for your most-used tools.
- tracker1 9y ago
  I'm not much into Hyper, but the terminal library has had a lot of performance improvements... VS Code uses the same terminal emulation library for its' integrated terminal and it saw some huge gains the past couple months.
rcarmo 9y ago
On a whim, and looking for a middle ground in native GUI editors, I fired up Textastic on my Mac (it's the most lightweight editor I have that does syntax highlighting and simple autocomplete), downloaded that text.xml file and opened it. Activity Monitor reported 29MB upon startup and 146MB RAM use with the file loaded, and moving to and from the end of the file is instantaneous (on a 7-year-old 2010 Mac Mini). Startup time is 1 seconds without a file (from typing "tt" in a terminal) and 2 when doing "tt test.xml". Search and replace for "thing" on every line was brutal, though. 5m32s, although I can't blame the editor - sampling the process, I see it doing a loop featuring CFStringCheckAndReplace, which is part of Core Foundation and likely not used to be subject to this kind of abuse - i.e., Textastic does not seem to use a custom internal buffer optimised for editing operations - it leverages what the OS already has. vim on this Mac is about as fast as described in the article, which is also why I generally stick to it. :) (edit: typos)
FlyingSnake 9y ago
I really wish developers stop using the JS editors and switch to platform specific editors. It's 2017 and all platforms have great native text editors, like Notepad++, GEdit, and if you need cross-platform, Sublime text. I don't see the point I using these electron based editors which waste tons of CPU cycles, and provide nothing of value.
- tracker1 9y ago
  Frankly, VS Code is WAY better in terms of plugin and configuration than any of the editors you mention.. from git integration, search, integrated terminal, integrated debugging with ui driven break points, etc, not even counting plugins. None of the editors you mention support those features. It's not wasting CPU cycles, and frankly even if it is, it's better than wasting my cycles having to switch between several terminal windows, apps, and file system browsers all because you don't think I shouldn't use an electron app.
  - kuschku 9y ago
    Then try out the JetBrains IDEs, and report back. All the features, none of the slowdown. I can't believe a Java IDE is actually faster than the new default editors.
    - IshKebab 9y ago
      The JetBrains IDEs are far slower then VSCode. Granted they do more, but they're still slow. And this is on a top-of-the-line MBP.
      - kuschku 9y ago
        I’ve ran the JetBrains IDEs on my thinkpad and desktop, and they’re consistently faster than VSCode when you compare them 1:1 (as in, you have a language plugin for that language + refactoring + co in VSCode).
    - charrondev 9y ago
whizzkid 9y ago
Little bit off topic but if you are afraid of opening large files on Mac OS, try Hex Fiend. It will open for example a 6GB database dump in mili-seconds (no joke) and it will let you search anything in it without you waiting. I just tested the memory usage with that 6GB dump file and it only requires 21MB to open that file. I discovered this program while checking who is behind my favorite shell (Fish Shell) :) http://ridiculousfish.com/ http://ridiculousfish.com/
mvid 9y ago
How does this compare to other full(er) featured editors like IntelliJ? I don't remember it taking that much RAM, and it's a workhorse.
philsnow 9y ago
the hero image with vim meanings on keyboard keys is pretty and apropos. my eyes were drawn to it and I found a typo: [pushes up glasses] There aren't ex commands ":ZZ" / ":ZQ", but "ZZ" and "ZQ" are normal mode commands.
staticelf 9y ago
Being in 2 slack teams use up as much memory as the entire visual studio 2017 does on my machine. It is electron that is the root cause here and it is the same for all electron based apps.
- DaiPlusPlus 9y ago
  Has anyone published a memory-map - a breakdown of what exactly is in the process' memory space - of these cases where Electron-based applications use orders-of-magnitude more memory than the native programs we used before? Previously I've remarked that high memory usage in web-browsers in itself is not a cause for alarm, and is mostly a good thing because it means the browser is aggressively caching assets so future pageloads will be much faster without needing to load things from disk - however that doesn't apply to Electron-based software because all of the assets are local already so there's nothing to cache that won't be loaded into memory already. So - I'm willing to bet that Electron's high memory usage is probably the JavaScript part - because a native DOM itself, even with all layout information and source assets for images and backgrounds, cannot be more than a few megabytes for even a complicated page (memory usage only shoots up once you start having to download 20MB+ autoplaying video ads). Then multiply the usage overhead of the V8 engine multiple times for the fact that Electron uses V8 to run Node internally, and for each process instance it spawns in the name of reliability - these child processes shouldn't be necessary: "desktop software" shouldn't be running untrusted scripts downloaded from the Internet (WebViews notwithstanding - but they can be isolated already) so adequate testing (and good software design) will ensure a JavaScript snippet will not bring down a process. If they insist on spamming processes, what does that say about their confidence in their code-quality? I'll join-in on the Slack-bashing. I know Slack is very capable and a breath of fresh air compared to Lync/Skype-for-Business, but right now it's consuming 755MB (70% private) between 6 slack.exe process instances on my machine - while the native Windows Telegram client (written in Qt) - with considerably more human-useful-data in-memory (over 200+ groups/channels/etc) is taking up a relatively miserly 133MB (85% private).
  - alex-e 9y ago
    There's a new native desktop app for Slack, Skype, WhatsApp, etc: https://eul.im/slack https://eul.im/slack It's only 4 MB and can handle tens of thousands of messages in one chat without lag.
ic4l 9y ago
So in other words use Sublime, or Vim.
hudo 9y ago
Not just that, for example GitKraken uses Electron, and consumes ~700MB RAM, compared to Smartgit that takes only 120MB on my machine.
davfer 9y ago
Even though a lot of people hate it, nano is a good editor as it has been stated in the stats. Maybe nano is a screwdriver what vim is a complete toolbox, and sublime a mechanical workshop (but paying a graphical requirement, like a rental fee)... Usually you only need to tighten a screw, other times fix a hose, others repair a car ;)
pedro2 9y ago
Thank you for the insight. I use Code and Notepad++, these analysis allow to predict which one I should use based on size as the factor.
_Codemonkeyism 9y ago
After using Atom on OS X and Windows for a long time, default installing it on every computer here at the company, I'm back to Notepad++ on Windows.
roryisok 9y ago
Title: "Why I Still Use Vim" First Two Lines: "Vim is my default editor. There’s no particular reason for this, except that I ended up learning it when I moved over to Linux many years ago. " Well, that's that then.
willvarfar 9y ago
I recall the Turbo Pascal text-mode IDE that left enough space to actually run the programs you were developing. The machines had 640KB RAM, and I think the IDE was using perhaps as much as 100KB. I recall using fully-featured GUI IDEs like VB, VC++ etc on machines with whopping 64MB RAM, and having enough space left to actually run the programs you were developing. I have a laptop now with 16GB RAM. The other day I tried to edit a large text log file in Atom and it ran out of memory. That was the first - and last - time I tried to use Atom. I went back to my fav editor, jEdit, which currently says in its tray that its using a whopping 28MB RAM. No idea what it can be doing to fill that up, as I have barely anything open. But still...
- bigato 9y ago
  Great comment for historical perspective. But just out of curiosity, why did you need to edit a log file?
  - willvarfar 9y ago
    just going to do fancy find replace. Sometimes when you have to actually read log files its easier in a text editor than on the command line.
    - bigato 9y ago
      Were you on windows? Because I can't imagine fancier find and replace than grep, awk, sed, cut and friends. Or maybe 'less' if you want to page and do simple searches. But maybe that's just because I'm used to these tools.
      - willvarfar 9y ago
        OSX and linux. I use the command line a lot. And often write scripts in python to chew through and transform logs. Still sometimes want to open big text files in GUI editors though...
- jmilloy 9y ago
Perados 9y ago
grabs popcorn
pksadiq 9y ago
Comparison with GNU Emacs seems not found. Or is it implicit that Eight Megabytes And Constantly Swapping?
franciscop 9y ago
I'd highly recommend to use log scales for the graphs. It doesn't have the same shock impact but it transmit the information much better.
swaincreates 9y ago
Blah blah this is ridiculous! Electron is horrible... blah blah... who cares? My macbook runs this fine and Atom is nice, blah blah, I switched to VS Code and its kinda nice, blah blah I tried this and went back to sublime... blah blah :q
- jimktrains2 9y ago
  People without copious amounts of memory?
papi0t 9y ago
Is this Jonathan Blow?
kowdermeister 9y ago
Something seems off, I just opened a 8.7MB file with Code and it still uses 264MB memory. (Win10) "> Conclusion Learn Vim." It's like saying "getting tired of long commuting?" Buy a Ferrari.
- makapuf 9y ago
  Except everyone can learn vim in a few days whereas not everyone can buy a Ferrari in a few days.
  - kowdermeister 9y ago
    I've heard multiple people stating that it took months of using it (and configuring it) until they kinda get used to vim. Not hard data, but interesting to read also: https://www.reddit.com/r/programming/comments/66wnd/how_long_does_one_have_to_use_vim_until_you_feel/ https://www.reddit.com/r/programming/comments/66wnd/how_long... When it takes reading tutorials to set up mouse + clipboard support, then I feel it's just simply not for me. It just irks me that someone finds editors bad that sacrifices resource handling in order to gain extreme flexibility and the he then concludes that the best thing to do is to learn something he spent probably a lots of time mastering. I skip tips from the ivory tower.
ceronman 9y ago
> Code requires a whopping 349 megabytes in order to open a 60 byte file. Atom comes in at 256 megabytes. Where Vim “only” needs 5 megabytes, which is still kind of high, but representative of an average configuration These numbers seem off. I just tested it and my VS Code uses 39MB of memory for loading a bunch of Python files and having a few plugins activated. Where are these numbers coming from? How was this test done? I switched from Vim to Sublime a while ago. For me Sublime feels much faster and user friendly. I'm now trying VS Code for Python, Go and Clojure. I know is not as fast as Sublime or Vim but it's really user friendly and I'm impress of how quickly the developers have been able to provide awesome functionality into their editor. That for me sounds like a fair tradeoff given that computers these days have several Gigabytes of memory.
- Matthias247 9y ago
  You need to be careful, because Code launches multiple subprocesses which you would all need to add up. I remember something around 250MB for basic file editing, which is fine for me.
nnq 9y ago
One question bugs me: how the hell did VSCode developers manage to get so incredibly much better performance (both low memory usage and responsiveness), using such a similar technical platform (also Node/js/Electron)?! There are surely lots of tricks to be learned from such a comparison, so if someone would dissect and compare Atom vs VSCode I'd even pay to read such an article!
- notamy 9y ago
  Discord too. A lot of people elsewhere in this thread are talking about how Slack is eating a ton of RAM and things like that, but (anecdotally, of course) Discord seems to be a lot better while using a lot less RAM. Personally, I can be in ~80 Discord "servers" that total to a few hundred thousand people and it's still using <500MB of RAM, so clearly it's possible to do a good job of resource management.
- thousande 9y ago
  I believe there is a podcast that discussed this. Unfortunately I can't remember which, Maybe one of these: https://programmingpodcasts.com/episode/net-rocks/building-visual-studio-code-with-sean-mcbreen https://programmingpodcasts.com/episode/net-rocks/building-v... https://programmingpodcasts.com/episode/javascript-jabber/240-jsj-visual-studio-code-with-chris-dias https://programmingpodcasts.com/episode/javascript-jabber/24... https://programmingpodcasts.com/episode/javascript-jabber/199-jsj-visual-studio-code-with-chris-dias-and-erich-gamma https://programmingpodcasts.com/episode/javascript-jabber/19... https://programmingpodcasts.com/episode/ms-dev-show/powershell-in-vs-code-with-david-wilson https://programmingpodcasts.com/episode/ms-dev-show/powershe... https://programmingpodcasts.com/episode/adventures-in-angular/044-aia-visual-studio-code-with-erich-gamma-and-chris-dias https://programmingpodcasts.com/episode/adventures-in-angula...
dodo 9y ago
Time waste to read. Nonsense article comparing pears and apples and he is believing he knows everything. It is not worth to discuss it.
primitivesuave 9y ago
Most people in CA prefer to drive a car rather than ride a bike. Bikes use far fewer resources to accomplish the same thing as a car (go from point A to B), but most people like to have the option of turning on the AC, playing music, and all the other add-ons that a car can bring to the experience. I personally choose to bike, but if I started making charts about the relative energy consumption of the two, I'd reach a similarly obvious conclusion. If I used those charts to convince people to start biking, I doubt I'd be very successful, since people usually have strong preferences to one over the other. One difference in this analogy is that cars pollute, whereas I couldn't care less how much memory your computer is using because it has practically zero impact on the environment or anyone other than yourself.
- jmilloy 9y ago
  This is an interesting analogy. > Bikes use far fewer resources to accomplish the same thing Bikes use a lot more time, which is a pretty important resource to most people. When I drive, that's usually why. So, are the additional features that Atom provides "driving saves significant time" variety or only "driving allows you to listen to the radio" variety? If the former, it might be worth the occasional freeze or slow down. > If I used those charts to convince people to start biking, I doubt I'd be very successful. I think if people actually didn't know that cars used more resources, the charts could have an impact on behavior. The fact that it's obvious (especially financially) means people already carpool or even (in cities) don't own a car at all. I don't think it's as obvious to some people that not every editor uses this much RAM, and you don't need another laptop upgrade, you can just switch to another editor. > I couldn't care less... because it has practically zero impact on the environment or anyone other than yourself I think you're right, but I'm not totally sure. If enough users refuse to use unreasonably resource-intensive software, then more effort will be spent on keeping most software efficient. We still seem to have plenty of options, but I'd rather try to convince others to use efficient software than eventually have to continually upgrade my hardware to keep up.
  - primitivesuave 9y ago
    This is an interesting response! For the first point, I'd say it's less about time as it is about ease-of-use. I still use Vim when I'm SSH'd somewhere or the common occasions where I just need to change one line of a file. The process of "vi", entering the editor, using the shortcuts to find, edit, replace, save the file is done before an editor even loads. Time is valuable and not using Vim in some situations is like choosing a hand saw over a power tool (my analogy game is on point today). On the last one about encouraging less resource-intensive software, I completely agree with you, and think software has grown increasingly careless toward memory usage. Unfortunately I'd estimate that less than 10% of computer users have ever opened the Activity Monitor on their mac or know which particular app is slowing it down. For developers I'm sure that's closer to 100%, so tools like Xcode/Atom/Eclipse will have their usage scrutinized more, but I certainly haven't seen anything close to mass rejection over it - we accept the free benefits and pay for it with better hardware. I also think the benefits of the underlying Electron library being seamless across platforms, plus the added benefit of extensions being as easy to write as a webpage, makes it a good trade-off for memory. I really don't mean to minimize or refute any point you just made, what you wrote makes a lot of sense and really got me thinking. Maybe car vs bike should be the analogy for a more convincing blog post ;)
sebastianconcpt 9y ago
I see large files as data to process instead of editing. Those sizes are unmanageable for editing. Doing an exceptional hack is fine, but normal workflow? If a file has more than 200 lines isn't time to think refactoring some component to aother file, and so on? Said that, I find Atom to be a good toot but also scandalous as pointed by the article. For me becomes a non-issue because I never find myself needing to edit such large files.
- maccard 9y ago
  200 lines? That's ridiculous. We have methods longer than 200 lines in our code. Splitting it into smaller methods would be a waste of time, and would make th code more complex. None of the logic is reusable, the intention is well documented and the code is all in one place, rather than having to jump around to 5 diffeeent files and step in to 1 line methods.
  - sebastianconcpt 9y ago
    Why ridiculous? I have the outcome you mention and more or less that metric. I have many methods that are one liners. As secondary benefit, it makes the code extraordinarily testable, reusable and flexible. When you code what's the prevailing paradigm you're using?
osrec 9y ago
I would love to use atom, but every time I install it, I find it slow and buggy (on my 6GB Linux machine). The code completion doesn't seem to work properly either, and that's the deal breaker. I reluctantly uninstall, and go back to eclipse or geany.
tjpnz 9y ago
I still can't for the life of me see why Electron was ever a good idea for apps like Atom. It's not like they haven't had to lean on native solutions before - they've already rewritten their JS based buffer in C++. Is it really that hard to find people who can write native UIs these days?
hasenj 9y ago
IntelliJ is just as heavy. Android studio is even heavier. If Sublime had features on par with Code I would happily use it. Though honestly I don't know much about Sublime. Can anyone comment on how it compares to Code?
atroll 9y ago
brackets is still the best
christogreeff 9y ago
I was intrigued by this article. So I tested it myself using VSCode 1.15.1 (x64), and a 6.16 MB (6 462 222 bytes) XML file. File opened in < 4 seconds. Uses about 180MB of memory. All 16013 lines show. Scrolling isn't an issue. Code folding isn't an issue. Memory usage dropped to 160MB, and then jumped to 330MB. Still high, but for me it works well and not a scenario I'd typically encounter.
BenGosub 9y ago
I like and use Atom, I started using it because I wanted a change from Sublime (not that there's anything wrong with Sublime). I have noticed though that it uses much more resources than Sublime so it drains my lap top battery faster and sometimes it feels slow.
lousken 9y ago
There should be a lot more focus on creating good multiplatform C++ GUI frameworks. Javascript is not the future.
ntrepid8 9y ago
I wonder if there is any possibility of using a newer iteration of Firefox with a configurable number of threads rather than Chrome as the engine for Electron (or something like it). In the browser at least this helps a lot to bring down memory consumption. Electron does more than just about any other tool to enable building high quality cross platform apps. As someone who runs Linux on the desktop it's quite nice to be able to use the same apps as folks running Mac/Win. I just don't have any computers with less than 16 GB of memory :)
sctb 9y ago
We've updated the title from “Atom uses nearly 1GB of RAM to open a 6MB file” to that of the article. Submitters, please don't write your own titles. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
deleted 9y ago
[deleted]
cdevs 9y ago
I didn't realize why I hated some of the concepts behind vim until I saw a recent article that explained the creator of vi was using the older style keyboard with esc and control keys in more convenient places as well as arrow graphics where movement keys are in vi. I know I would have loved it back then but I also know that if it were created today decisions would be very different and could be better right from the start with out me having to mod the hell out of it. I'm not good at keeping config files for my personal setups from matchine to machine and I wipe operating systems and try new ones all the time, just doesn't click with me. I'm sure if I stuck with it and these things were second nature I would love it.
- SuperPaintMan 9y ago
  Yeah, vim with a standard querty layout is just painful. I have a few configs floating about that swap esc & tilde, turn caps into another control. Using Vim with anything else is a quick way to destroying my pinky. A few years ago I started rebinding my window controls to be more Vim like (alt-j/k instead of cmd-tab and the like) and noticed less strain. Eventually installed Vimium in Chrome so I could browse using my keyboard and noticed similar reduction of strain. Did you know you can enable vi-editing in your shell with `set -o vi`? Oh god now I've installed Xmonad and the vi bindings are everywhere. Four shells on a desktop, devtools over there alt-HL for monitor control, flick the J to swap windows, build scripts singing along the bottom. It's fucking horrible and I love it. Vim is love, Vim is life.
  - hood_syntax 9y ago
    > Oh god now I've installed Xmonad and the vi bindings are everywhere Tell me about it :|
alkonaut 9y ago
How much cpu and memory you can accept being used is depending on what you get for it. An IDE is always going to hog a lot more memory than an editor because typically they will keep hundreds of files in memory, do some kind of syntax analysis (and keep the results such as AST's in memory the whole time) to be able to provide symbol navigation and so on. There is of course wasted memory here in the case of electron, because while I'm happy for the editor to use memory for things I want (that will help me be more productive than in the plainest of editors) I'm not very happy to let an editor use hundreds of megs e.g. just for rendering text. What is it in electron editors that takes so much memory, in the case of a simple file?
- nonsince 9y ago
  Storing hundreds of files in memory is absolutely not necessary. You can incrementally page files in and out, keeping the total size low. Anything that requires an entire file to be loaded instead of using some structure like an automatically-loaded/unloaded rope is asking to make an editor that crashes when you use it to read a log. Same for ASTs. If you're lazy, just allocate it in a memmap, but there are smarter ways to do it. There's a great series by a Google engineer about their project "Xi" https://github.com/google/xi-editor/tree/master/doc/rope_science https://github.com/google/xi-editor/tree/master/doc/rope_sci...
  - alkonaut 9y ago
    > Storing hundreds of files in memory is absolutely not necessary. You can incrementally page files in and out, keeping the total size low. The metadata such as symbol lookup data for a project of say 10k source files is going to be larger than the source itself. The source might be 10-100mb but the data you need in memory in order to e.g. do error highlighting and symbol navigation without having to re-parse code is going to be a lot larger than that. And all of that is IN context, i.e. once you loaded 10k source files you could theoretically page out the text content of non-visible files, but all the metadata about symbols etc is still required to be in memory - the whole time. Obviously if you view a huge file the actual text content of the file is a memory concern in itself - and then you need a high perf data structure for the text itself. This is exactly why a text editor and an IDE are good for different things.
JoshMnem 9y ago
Vim is the best brain-computer interface I've experienced. Once you have enough commands in muscle memory, you can think about what you want the text to do, and it happens. You can look at the screen, decide what you want to do, and then perform complex edits with your eyes closed. I would liken Vim's editing experience to doing kung fu in your head. I tried Atom, but it does not have passable Vim emulation. Sublime's is passable, but many things are missing in comparison to Vim (or neovim).
zelos 9y ago
It looks like Atom is at least moving in the right direction - I see 736MB RAM on OSX with that 6MB XML file open. For me it's less the RAM usage and more latency that annoys me. Things like the way you can see the syntax highlighting being done down the screen in even small file, or the half second delay switching channels in Slack.
hungerstrike 9y ago
> Using Atom or Code I experience frequent freezes for several minutes when just typing a single character. Sounds like a Linux problem. VS Code works great for me on Windows and the Apple Macintosh OS.
saghm 9y ago
(Meta comment on the dicussion here) I find it mind-boggling why so many people have such strong emotions about other people's preferences for things that don't affect them. While I have preferences for what editors I like to use, I don't understand why various strangers on the internet having different preferences would be so upsetting to people. Once you extend this to other areas of life, it becomes even more obviously silly; I personally find the smell and taste of bacon rather repugnant, but there are a lot of people who really enjoy it, and I don't feel the need to criticize them for it. Why should it be any different with text editors?
alexeiz 9y ago
Trigger warning: the author is a Vim apologist/Emacs denier. /s
thedonkeycometh 9y ago
I don't think Atom is meant to open huge files, its meant for web development work where files are relatively short, and work is split up. So, i guess they don't have a test plan for large files, so they don't deliver something that can handle them, basically because its not meant to. And i'm ok with that. It gives me more than Vim.
pjmlp 9y ago
I just realized even Eclipse uses less memory than Atom.
amai 9y ago
I use IntelliJ IDEA. Everything else is for kids.
FullMtlAlcoholc 9y ago
These types of articles are little, if anything, more than pure fanboy-ism that is littered with hyperbolic claims. I'm running a 2013 Macbook pro w/ 8 GB of RAM, the Intel Iris graphic card, sttached to two external, stacked Ultra wide HD monitors(sometimes a 3rd 1080p in portrait). The only "upgrade" it has received is an extra SSD installed after I removed the optical drive. You would be insulted if, as a dev, a company gave you this as a workstation in 2017. Currently, I am running 8 electron apps(Slack, Discord, Headset, kiwi for Gmail, Insomnia as a GraphQL client, Visual Studio Code, Hyper as my terminal emulator, Spotify. When I feel like being unproductive, I open Pocket and push the total to 9) Bartender manages another dozen+ apps. Oh, and I also have open Chrome, Chrome Canary, Firefox Nightly, and Opera Neon. Chrome is running with 60 or so enabled extensions, Firefox has another 15 active add ons. And between all the browsers, I usually have around 75 open tabs, 18 or so sre running video or some other resource intrnsive media.As well as the occasional Linux VM. Iused to run the McAfee Global Threat map animation as a live background, but that was a little too much. Depending on what Im working on, Im usually running at least 4 or 5 servers. none that have to deal with huge amoubts of data, as id usually just provision cloud resources for that. Did I mention my 2013 8 GB MacBook handles this with ease? If I had a more powerful workstation, it would nit make me any more productive. I type at around 100-110 wpm and a more powerful machine wouldnt allow me to interface faster. So, when ornery devs violate the DRY principle on every single HN thread that is tangentially related to electron and trash it with an exuberance that would make McCarthy proud, I wonder, why? I imagine most have more powerful workstations than my own. I understand it from the perspective of those who have hundreds or thousands of tabs open (Around 30 or do open tabs causes cognitive overload for me and refuces productivity the more i have open.) I did have issues when running Atom and trying to open 30MB log and JSON files, but I wiuld also usually have 4 or more open projects. Ive since moved to VSCode after a year of apprehension due to having to give up ny many atom extensions, without looking back It doesnt sound like the author is doing anything that complex. There is no way that it takes minutes to open a 6MB log file, especially if using the newer version of atom. The idea that electron brings yoyr system to a crawl is simply not true, especially one app(unless its Atom). Electron apps work. The performance benefits of native apps are negligible on my productivity . And, usually, their aesthetics are a hindrance as I like ny apps to be visually appealing. All the other cross-platform solutions almost always look like crap. But this is only important if one values those particular aesthetics of which i speak. So, the attacks remind me of the discussion of artificial benchmarks comparing gpus or game consoles... immaterial and irrelevant to actual usage. Its an argument of pitentials and thereoticals never achieved. Especially for a freaking web developer. Even if you disagree with me, these threads are trash because nothing new or original is said. Just the complaints about the "kids these days" from a small, but extremely vocal minority whose comments are in stark contrast to the threads overall karma. Oh, and if If you're working out of emacs, electron apps are not for you.

168 points by johnsnow0 9y ago

I use both vim and atom, but I can't imagine writing code all the time in vim.

How much of that is fixed cost? i.e. how much of that 1Gb is still consumed if you have no file (or a single empty file) open and how much is consumed when you open a second 6MB file?

Marazan 9y ago
It took 256 Meg to open a 60 byte file. So we can probably assume that is the floor.
- monsieurbanana 9y ago
  Was it the first file open? Or the first of it's kind? I doubt atom will use 2.5 gb to open ten 60 byte files.
nothrabannosir 9y ago
That's the first point of the article. Well before the titular 6MB file.
- dspillett 9y ago
  Ah, I skipped the article assuming from the post title here it would be the usual overly breathy "look at this one number, aren't I clever for thinking it silly". I see the title here has been improved. I would suggest something more meaningful but not much longer though, something like "Why I Still Use Vim: memory Use By Code Editors".

kristopolous 9y ago

A good thing to learn is gnu ed. You can navigate around, replace text, append, prepend and delete lines on a 1GB file using a few KB of memory.

sovok 9y ago
It's the standard editor after all https://www.gnu.org/fun/jokes/ed-msg.html https://www.gnu.org/fun/jokes/ed-msg.html

Klathmon 9y ago

These kinds of comparisons always seemed a bit silly to me. It's like complaining that opening a 6MB file in windows took over 3GB on my system! (ignoring that most of that is the OS getting ready to do other things, and enabling the OS to do things other than opening and reading a 6MB file). Yes, Atom isn't the most resource friendly editor out there, and nobody is claiming it is. But it is one of the more capable editors out there. That 1GB allows for things like easy theming, inline image viewing, styling/theming via CSS, plugins/extensions written in a web language (which many of it's target demographic use), complete freedom for plugins to do almost anything and everything, a full web browser for easily rendering markdown/websites-in-progress/documentation/etc, code linting, compiling, debugging, decompiling, etc... Not to mention that a 6MB file is pretty fucking big for something like atom. Yes, I know, 6MB isn't "big", but for an editor which is designed to only work on source files which are AT MOST a MB, it's big. If all you are going to do is open a 6MB file with none of that, then stop using it, and stop acting like it's bad software because it doesn't cater to your needs. Vim won't show me 4 panes with ES2016 in one, the compiled version in scrolling-lockstep with the ES2016 pane in the next, and a visual preview of the page as it currently is in the 3rd, and the documentation to a function i'm working on in the 4th. That still doesn't mean it's bad software, just that it's not a good fit when compared to the alternatives for me. Stop complaining that the hammer is better than the screwdriver because it can hammer in nails better.

konart 9y ago
>which many of it's target demographic use So true, I almost posted a joke as a comment, only to delete it before actually commmiting a crime. >Vim won't show me 4 panes with ES2016 in one... I'm pretty sure most of this is doable though (not a Vim user)
- deleted 9y ago
  [deleted]
- zacmps 9y ago
  It can do all but the third. Vim's understandably limited to displaying fixed size characters and so can't render webpages. Hoover projects like Oni, Nyaovim or gonvim (All built on neovim) have the potential to change this (If they haven't already).

molestrangler 9y ago

I gave up on Atom when I found MS Visual Code, for this very reason.

tracker1 9y ago
To be fair, up until the latest VS Code release, it didn't do very well with larger files either... much better since 1.15, but I rarely have to look at a file that big.

deleted 9y ago

[deleted]

OrangeTux 9y ago

Nothing new, right? A lot of Electron based apps use lots of memory.

mugsie 9y ago

The other takeaway from this is that if (like me) you prefer a GUI / X style editor, sublime text is a pretty good contender. Personally, I really like Sublime, it was one of the best returns on investment for me (even buying it twice).

algoexpt 9y ago

Or use sublime text. Seems to fare well.

dingari 9y ago

What I take from this is to continue using Sublime...

tombh 9y ago

> I’ve primarily stuck with [vim] because it’s an extensible editor that doesn’t hog all the resources and kill my machines. Exactly, BUT ... Vim has a non-mainstream shortcut interface, which I've always thought is an unfortunate caveat. So over the years I've actually managed to massage Vim into behaving like a 'normal' editor. It fits into a plugin if you're interested: https://github.com/tombh/novim-mode https://github.com/tombh/novim-mode

annabellish 9y ago
But then what's... the point? That vim has a rich and expressive language for text navigation and manipulation is the only thing that sets it apart from more modern competitors.
- tombh 9y ago
  That was the part of the sentiment of the quote - the point is that Vim is notable for 2 distinct, but unfortunately inseparable, reasons; 1. Modal editing. 2. One of the most ubiquitous, lightweight, stable and extensible editors in existence. I just want there to be at least a semblance of a possibility to separate these 2 things.
  - jimktrains2 9y ago
    Have you tried emacs?
    - tombh 9y ago
      Yes, but it doesn't exactly have 'conventional' shortcuts either, right? It's a little more heavyweight over Vim as well. So in the light-but-powerful editor universe, I think Vim just pips it to the post. Which is why I use it, albeit with 'normal' shortcuts.
      - jimktrains2 9y ago
        Depends on what you mean by conventional. It's the default key binding style in most terminals.

rangibaby 9y ago

I actually care more about power usage than anything else these days. If it takes 1GB of memory to do that then so be it; that's cool (literally) /EDIT this comment refers to the general case not Atom in particular

eivarv 9y ago
Aren't Electron apps such as Atom known to have a significant impact on battery life/power usage?

samdoidge 9y ago

I've tried Atom - quickly went back to Sublime from my speed tests. I had a similar speed issues with https://hyper.is https://hyper.is vs iTerm. These new tools look pretty but performance matters, especially for your most-used tools.

tracker1 9y ago
I'm not much into Hyper, but the terminal library has had a lot of performance improvements... VS Code uses the same terminal emulation library for its' integrated terminal and it saw some huge gains the past couple months.

rcarmo 9y ago

On a whim, and looking for a middle ground in native GUI editors, I fired up Textastic on my Mac (it's the most lightweight editor I have that does syntax highlighting and simple autocomplete), downloaded that text.xml file and opened it. Activity Monitor reported 29MB upon startup and 146MB RAM use with the file loaded, and moving to and from the end of the file is instantaneous (on a 7-year-old 2010 Mac Mini). Startup time is 1 seconds without a file (from typing "tt" in a terminal) and 2 when doing "tt test.xml". Search and replace for "thing" on every line was brutal, though. 5m32s, although I can't blame the editor - sampling the process, I see it doing a loop featuring CFStringCheckAndReplace, which is part of Core Foundation and likely not used to be subject to this kind of abuse - i.e., Textastic does not seem to use a custom internal buffer optimised for editing operations - it leverages what the OS already has. vim on this Mac is about as fast as described in the article, which is also why I generally stick to it. :) (edit: typos)

FlyingSnake 9y ago

I really wish developers stop using the JS editors and switch to platform specific editors. It's 2017 and all platforms have great native text editors, like Notepad++, GEdit, and if you need cross-platform, Sublime text. I don't see the point I using these electron based editors which waste tons of CPU cycles, and provide nothing of value.

tracker1 9y ago
Frankly, VS Code is WAY better in terms of plugin and configuration than any of the editors you mention.. from git integration, search, integrated terminal, integrated debugging with ui driven break points, etc, not even counting plugins. None of the editors you mention support those features. It's not wasting CPU cycles, and frankly even if it is, it's better than wasting my cycles having to switch between several terminal windows, apps, and file system browsers all because you don't think I shouldn't use an electron app.
- kuschku 9y ago
  Then try out the JetBrains IDEs, and report back. All the features, none of the slowdown. I can't believe a Java IDE is actually faster than the new default editors.
  - IshKebab 9y ago
    The JetBrains IDEs are far slower then VSCode. Granted they do more, but they're still slow. And this is on a top-of-the-line MBP.
    - kuschku 9y ago
      I’ve ran the JetBrains IDEs on my thinkpad and desktop, and they’re consistently faster than VSCode when you compare them 1:1 (as in, you have a language plugin for that language + refactoring + co in VSCode).
  - charrondev 9y ago

whizzkid 9y ago

Little bit off topic but if you are afraid of opening large files on Mac OS, try Hex Fiend. It will open for example a 6GB database dump in mili-seconds (no joke) and it will let you search anything in it without you waiting. I just tested the memory usage with that 6GB dump file and it only requires 21MB to open that file. I discovered this program while checking who is behind my favorite shell (Fish Shell) :) http://ridiculousfish.com/ http://ridiculousfish.com/

mvid 9y ago

How does this compare to other full(er) featured editors like IntelliJ? I don't remember it taking that much RAM, and it's a workhorse.

philsnow 9y ago

the hero image with vim meanings on keyboard keys is pretty and apropos. my eyes were drawn to it and I found a typo: [pushes up glasses] There aren't ex commands ":ZZ" / ":ZQ", but "ZZ" and "ZQ" are normal mode commands.

staticelf 9y ago

Being in 2 slack teams use up as much memory as the entire visual studio 2017 does on my machine. It is electron that is the root cause here and it is the same for all electron based apps.

DaiPlusPlus 9y ago
Has anyone published a memory-map - a breakdown of what exactly is in the process' memory space - of these cases where Electron-based applications use orders-of-magnitude more memory than the native programs we used before? Previously I've remarked that high memory usage in web-browsers in itself is not a cause for alarm, and is mostly a good thing because it means the browser is aggressively caching assets so future pageloads will be much faster without needing to load things from disk - however that doesn't apply to Electron-based software because all of the assets are local already so there's nothing to cache that won't be loaded into memory already. So - I'm willing to bet that Electron's high memory usage is probably the JavaScript part - because a native DOM itself, even with all layout information and source assets for images and backgrounds, cannot be more than a few megabytes for even a complicated page (memory usage only shoots up once you start having to download 20MB+ autoplaying video ads). Then multiply the usage overhead of the V8 engine multiple times for the fact that Electron uses V8 to run Node internally, and for each process instance it spawns in the name of reliability - these child processes shouldn't be necessary: "desktop software" shouldn't be running untrusted scripts downloaded from the Internet (WebViews notwithstanding - but they can be isolated already) so adequate testing (and good software design) will ensure a JavaScript snippet will not bring down a process. If they insist on spamming processes, what does that say about their confidence in their code-quality? I'll join-in on the Slack-bashing. I know Slack is very capable and a breath of fresh air compared to Lync/Skype-for-Business, but right now it's consuming 755MB (70% private) between 6 slack.exe process instances on my machine - while the native Windows Telegram client (written in Qt) - with considerably more human-useful-data in-memory (over 200+ groups/channels/etc) is taking up a relatively miserly 133MB (85% private).
- alex-e 9y ago
  There's a new native desktop app for Slack, Skype, WhatsApp, etc: https://eul.im/slack https://eul.im/slack It's only 4 MB and can handle tens of thousands of messages in one chat without lag.

ic4l 9y ago

So in other words use Sublime, or Vim.

hudo 9y ago

Not just that, for example GitKraken uses Electron, and consumes ~700MB RAM, compared to Smartgit that takes only 120MB on my machine.

davfer 9y ago

Even though a lot of people hate it, nano is a good editor as it has been stated in the stats. Maybe nano is a screwdriver what vim is a complete toolbox, and sublime a mechanical workshop (but paying a graphical requirement, like a rental fee)... Usually you only need to tighten a screw, other times fix a hose, others repair a car ;)

pedro2 9y ago

Thank you for the insight. I use Code and Notepad++, these analysis allow to predict which one I should use based on size as the factor.

_Codemonkeyism 9y ago

After using Atom on OS X and Windows for a long time, default installing it on every computer here at the company, I'm back to Notepad++ on Windows.

roryisok 9y ago

Title: "Why I Still Use Vim" First Two Lines: "Vim is my default editor. There’s no particular reason for this, except that I ended up learning it when I moved over to Linux many years ago. " Well, that's that then.

willvarfar 9y ago

I recall the Turbo Pascal text-mode IDE that left enough space to actually run the programs you were developing. The machines had 640KB RAM, and I think the IDE was using perhaps as much as 100KB. I recall using fully-featured GUI IDEs like VB, VC++ etc on machines with whopping 64MB RAM, and having enough space left to actually run the programs you were developing. I have a laptop now with 16GB RAM. The other day I tried to edit a large text log file in Atom and it ran out of memory. That was the first - and last - time I tried to use Atom. I went back to my fav editor, jEdit, which currently says in its tray that its using a whopping 28MB RAM. No idea what it can be doing to fill that up, as I have barely anything open. But still...

bigato 9y ago
Great comment for historical perspective. But just out of curiosity, why did you need to edit a log file?
- willvarfar 9y ago
  just going to do fancy find replace. Sometimes when you have to actually read log files its easier in a text editor than on the command line.
  - bigato 9y ago
    Were you on windows? Because I can't imagine fancier find and replace than grep, awk, sed, cut and friends. Or maybe 'less' if you want to page and do simple searches. But maybe that's just because I'm used to these tools.
    - willvarfar 9y ago
      OSX and linux. I use the command line a lot. And often write scripts in python to chew through and transform logs. Still sometimes want to open big text files in GUI editors though...
jmilloy 9y ago

Perados 9y ago

grabs popcorn

pksadiq 9y ago

Comparison with GNU Emacs seems not found. Or is it implicit that Eight Megabytes And Constantly Swapping?

franciscop 9y ago

I'd highly recommend to use log scales for the graphs. It doesn't have the same shock impact but it transmit the information much better.

swaincreates 9y ago

Blah blah this is ridiculous! Electron is horrible... blah blah... who cares? My macbook runs this fine and Atom is nice, blah blah, I switched to VS Code and its kinda nice, blah blah I tried this and went back to sublime... blah blah :q

jimktrains2 9y ago
People without copious amounts of memory?

papi0t 9y ago

Is this Jonathan Blow?

kowdermeister 9y ago

Something seems off, I just opened a 8.7MB file with Code and it still uses 264MB memory. (Win10) "> Conclusion Learn Vim." It's like saying "getting tired of long commuting?" Buy a Ferrari.

makapuf 9y ago
Except everyone can learn vim in a few days whereas not everyone can buy a Ferrari in a few days.
- kowdermeister 9y ago
  I've heard multiple people stating that it took months of using it (and configuring it) until they kinda get used to vim. Not hard data, but interesting to read also: https://www.reddit.com/r/programming/comments/66wnd/how_long_does_one_have_to_use_vim_until_you_feel/ https://www.reddit.com/r/programming/comments/66wnd/how_long... When it takes reading tutorials to set up mouse + clipboard support, then I feel it's just simply not for me. It just irks me that someone finds editors bad that sacrifices resource handling in order to gain extreme flexibility and the he then concludes that the best thing to do is to learn something he spent probably a lots of time mastering. I skip tips from the ivory tower.

ceronman 9y ago

> Code requires a whopping 349 megabytes in order to open a 60 byte file. Atom comes in at 256 megabytes. Where Vim “only” needs 5 megabytes, which is still kind of high, but representative of an average configuration These numbers seem off. I just tested it and my VS Code uses 39MB of memory for loading a bunch of Python files and having a few plugins activated. Where are these numbers coming from? How was this test done? I switched from Vim to Sublime a while ago. For me Sublime feels much faster and user friendly. I'm now trying VS Code for Python, Go and Clojure. I know is not as fast as Sublime or Vim but it's really user friendly and I'm impress of how quickly the developers have been able to provide awesome functionality into their editor. That for me sounds like a fair tradeoff given that computers these days have several Gigabytes of memory.

Matthias247 9y ago
You need to be careful, because Code launches multiple subprocesses which you would all need to add up. I remember something around 250MB for basic file editing, which is fine for me.

nnq 9y ago

One question bugs me: how the hell did VSCode developers manage to get so incredibly much better performance (both low memory usage and responsiveness), using such a similar technical platform (also Node/js/Electron)?! There are surely lots of tricks to be learned from such a comparison, so if someone would dissect and compare Atom vs VSCode I'd even pay to read such an article!

notamy 9y ago
Discord too. A lot of people elsewhere in this thread are talking about how Slack is eating a ton of RAM and things like that, but (anecdotally, of course) Discord seems to be a lot better while using a lot less RAM. Personally, I can be in ~80 Discord "servers" that total to a few hundred thousand people and it's still using <500MB of RAM, so clearly it's possible to do a good job of resource management.
thousande 9y ago
I believe there is a podcast that discussed this. Unfortunately I can't remember which, Maybe one of these: https://programmingpodcasts.com/episode/net-rocks/building-visual-studio-code-with-sean-mcbreen https://programmingpodcasts.com/episode/net-rocks/building-v... https://programmingpodcasts.com/episode/javascript-jabber/240-jsj-visual-studio-code-with-chris-dias https://programmingpodcasts.com/episode/javascript-jabber/24... https://programmingpodcasts.com/episode/javascript-jabber/199-jsj-visual-studio-code-with-chris-dias-and-erich-gamma https://programmingpodcasts.com/episode/javascript-jabber/19... https://programmingpodcasts.com/episode/ms-dev-show/powershell-in-vs-code-with-david-wilson https://programmingpodcasts.com/episode/ms-dev-show/powershe... https://programmingpodcasts.com/episode/adventures-in-angular/044-aia-visual-studio-code-with-erich-gamma-and-chris-dias https://programmingpodcasts.com/episode/adventures-in-angula...

dodo 9y ago

Time waste to read. Nonsense article comparing pears and apples and he is believing he knows everything. It is not worth to discuss it.

primitivesuave 9y ago

Most people in CA prefer to drive a car rather than ride a bike. Bikes use far fewer resources to accomplish the same thing as a car (go from point A to B), but most people like to have the option of turning on the AC, playing music, and all the other add-ons that a car can bring to the experience. I personally choose to bike, but if I started making charts about the relative energy consumption of the two, I'd reach a similarly obvious conclusion. If I used those charts to convince people to start biking, I doubt I'd be very successful, since people usually have strong preferences to one over the other. One difference in this analogy is that cars pollute, whereas I couldn't care less how much memory your computer is using because it has practically zero impact on the environment or anyone other than yourself.

jmilloy 9y ago
This is an interesting analogy. > Bikes use far fewer resources to accomplish the same thing Bikes use a lot more time, which is a pretty important resource to most people. When I drive, that's usually why. So, are the additional features that Atom provides "driving saves significant time" variety or only "driving allows you to listen to the radio" variety? If the former, it might be worth the occasional freeze or slow down. > If I used those charts to convince people to start biking, I doubt I'd be very successful. I think if people actually didn't know that cars used more resources, the charts could have an impact on behavior. The fact that it's obvious (especially financially) means people already carpool or even (in cities) don't own a car at all. I don't think it's as obvious to some people that not every editor uses this much RAM, and you don't need another laptop upgrade, you can just switch to another editor. > I couldn't care less... because it has practically zero impact on the environment or anyone other than yourself I think you're right, but I'm not totally sure. If enough users refuse to use unreasonably resource-intensive software, then more effort will be spent on keeping most software efficient. We still seem to have plenty of options, but I'd rather try to convince others to use efficient software than eventually have to continually upgrade my hardware to keep up.
- primitivesuave 9y ago
  This is an interesting response! For the first point, I'd say it's less about time as it is about ease-of-use. I still use Vim when I'm SSH'd somewhere or the common occasions where I just need to change one line of a file. The process of "vi", entering the editor, using the shortcuts to find, edit, replace, save the file is done before an editor even loads. Time is valuable and not using Vim in some situations is like choosing a hand saw over a power tool (my analogy game is on point today). On the last one about encouraging less resource-intensive software, I completely agree with you, and think software has grown increasingly careless toward memory usage. Unfortunately I'd estimate that less than 10% of computer users have ever opened the Activity Monitor on their mac or know which particular app is slowing it down. For developers I'm sure that's closer to 100%, so tools like Xcode/Atom/Eclipse will have their usage scrutinized more, but I certainly haven't seen anything close to mass rejection over it - we accept the free benefits and pay for it with better hardware. I also think the benefits of the underlying Electron library being seamless across platforms, plus the added benefit of extensions being as easy to write as a webpage, makes it a good trade-off for memory. I really don't mean to minimize or refute any point you just made, what you wrote makes a lot of sense and really got me thinking. Maybe car vs bike should be the analogy for a more convincing blog post ;)

sebastianconcpt 9y ago

I see large files as data to process instead of editing. Those sizes are unmanageable for editing. Doing an exceptional hack is fine, but normal workflow? If a file has more than 200 lines isn't time to think refactoring some component to aother file, and so on? Said that, I find Atom to be a good toot but also scandalous as pointed by the article. For me becomes a non-issue because I never find myself needing to edit such large files.

maccard 9y ago
200 lines? That's ridiculous. We have methods longer than 200 lines in our code. Splitting it into smaller methods would be a waste of time, and would make th code more complex. None of the logic is reusable, the intention is well documented and the code is all in one place, rather than having to jump around to 5 diffeeent files and step in to 1 line methods.
- sebastianconcpt 9y ago
  Why ridiculous? I have the outcome you mention and more or less that metric. I have many methods that are one liners. As secondary benefit, it makes the code extraordinarily testable, reusable and flexible. When you code what's the prevailing paradigm you're using?

osrec 9y ago

I would love to use atom, but every time I install it, I find it slow and buggy (on my 6GB Linux machine). The code completion doesn't seem to work properly either, and that's the deal breaker. I reluctantly uninstall, and go back to eclipse or geany.

tjpnz 9y ago

I still can't for the life of me see why Electron was ever a good idea for apps like Atom. It's not like they haven't had to lean on native solutions before - they've already rewritten their JS based buffer in C++. Is it really that hard to find people who can write native UIs these days?

hasenj 9y ago

IntelliJ is just as heavy. Android studio is even heavier. If Sublime had features on par with Code I would happily use it. Though honestly I don't know much about Sublime. Can anyone comment on how it compares to Code?

atroll 9y ago

brackets is still the best

christogreeff 9y ago

I was intrigued by this article. So I tested it myself using VSCode 1.15.1 (x64), and a 6.16 MB (6 462 222 bytes) XML file. File opened in < 4 seconds. Uses about 180MB of memory. All 16013 lines show. Scrolling isn't an issue. Code folding isn't an issue. Memory usage dropped to 160MB, and then jumped to 330MB. Still high, but for me it works well and not a scenario I'd typically encounter.

BenGosub 9y ago

I like and use Atom, I started using it because I wanted a change from Sublime (not that there's anything wrong with Sublime). I have noticed though that it uses much more resources than Sublime so it drains my lap top battery faster and sometimes it feels slow.

lousken 9y ago

There should be a lot more focus on creating good multiplatform C++ GUI frameworks. Javascript is not the future.

ntrepid8 9y ago

I wonder if there is any possibility of using a newer iteration of Firefox with a configurable number of threads rather than Chrome as the engine for Electron (or something like it). In the browser at least this helps a lot to bring down memory consumption. Electron does more than just about any other tool to enable building high quality cross platform apps. As someone who runs Linux on the desktop it's quite nice to be able to use the same apps as folks running Mac/Win. I just don't have any computers with less than 16 GB of memory :)

sctb 9y ago

We've updated the title from “Atom uses nearly 1GB of RAM to open a 6MB file” to that of the article. Submitters, please don't write your own titles. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

deleted 9y ago

[deleted]

cdevs 9y ago

I didn't realize why I hated some of the concepts behind vim until I saw a recent article that explained the creator of vi was using the older style keyboard with esc and control keys in more convenient places as well as arrow graphics where movement keys are in vi. I know I would have loved it back then but I also know that if it were created today decisions would be very different and could be better right from the start with out me having to mod the hell out of it. I'm not good at keeping config files for my personal setups from matchine to machine and I wipe operating systems and try new ones all the time, just doesn't click with me. I'm sure if I stuck with it and these things were second nature I would love it.

SuperPaintMan 9y ago
Yeah, vim with a standard querty layout is just painful. I have a few configs floating about that swap esc & tilde, turn caps into another control. Using Vim with anything else is a quick way to destroying my pinky. A few years ago I started rebinding my window controls to be more Vim like (alt-j/k instead of cmd-tab and the like) and noticed less strain. Eventually installed Vimium in Chrome so I could browse using my keyboard and noticed similar reduction of strain. Did you know you can enable vi-editing in your shell with `set -o vi`? Oh god now I've installed Xmonad and the vi bindings are everywhere. Four shells on a desktop, devtools over there alt-HL for monitor control, flick the J to swap windows, build scripts singing along the bottom. It's fucking horrible and I love it. Vim is love, Vim is life.
- hood_syntax 9y ago
  > Oh god now I've installed Xmonad and the vi bindings are everywhere Tell me about it :|

alkonaut 9y ago

How much cpu and memory you can accept being used is depending on what you get for it. An IDE is always going to hog a lot more memory than an editor because typically they will keep hundreds of files in memory, do some kind of syntax analysis (and keep the results such as AST's in memory the whole time) to be able to provide symbol navigation and so on. There is of course wasted memory here in the case of electron, because while I'm happy for the editor to use memory for things I want (that will help me be more productive than in the plainest of editors) I'm not very happy to let an editor use hundreds of megs e.g. just for rendering text. What is it in electron editors that takes so much memory, in the case of a simple file?

nonsince 9y ago
Storing hundreds of files in memory is absolutely not necessary. You can incrementally page files in and out, keeping the total size low. Anything that requires an entire file to be loaded instead of using some structure like an automatically-loaded/unloaded rope is asking to make an editor that crashes when you use it to read a log. Same for ASTs. If you're lazy, just allocate it in a memmap, but there are smarter ways to do it. There's a great series by a Google engineer about their project "Xi" https://github.com/google/xi-editor/tree/master/doc/rope_science https://github.com/google/xi-editor/tree/master/doc/rope_sci...
- alkonaut 9y ago
  > Storing hundreds of files in memory is absolutely not necessary. You can incrementally page files in and out, keeping the total size low. The metadata such as symbol lookup data for a project of say 10k source files is going to be larger than the source itself. The source might be 10-100mb but the data you need in memory in order to e.g. do error highlighting and symbol navigation without having to re-parse code is going to be a lot larger than that. And all of that is IN context, i.e. once you loaded 10k source files you could theoretically page out the text content of non-visible files, but all the metadata about symbols etc is still required to be in memory - the whole time. Obviously if you view a huge file the actual text content of the file is a memory concern in itself - and then you need a high perf data structure for the text itself. This is exactly why a text editor and an IDE are good for different things.

JoshMnem 9y ago

Vim is the best brain-computer interface I've experienced. Once you have enough commands in muscle memory, you can think about what you want the text to do, and it happens. You can look at the screen, decide what you want to do, and then perform complex edits with your eyes closed. I would liken Vim's editing experience to doing kung fu in your head. I tried Atom, but it does not have passable Vim emulation. Sublime's is passable, but many things are missing in comparison to Vim (or neovim).

zelos 9y ago

It looks like Atom is at least moving in the right direction - I see 736MB RAM on OSX with that 6MB XML file open. For me it's less the RAM usage and more latency that annoys me. Things like the way you can see the syntax highlighting being done down the screen in even small file, or the half second delay switching channels in Slack.

hungerstrike 9y ago

> Using Atom or Code I experience frequent freezes for several minutes when just typing a single character. Sounds like a Linux problem. VS Code works great for me on Windows and the Apple Macintosh OS.

saghm 9y ago

(Meta comment on the dicussion here) I find it mind-boggling why so many people have such strong emotions about other people's preferences for things that don't affect them. While I have preferences for what editors I like to use, I don't understand why various strangers on the internet having different preferences would be so upsetting to people. Once you extend this to other areas of life, it becomes even more obviously silly; I personally find the smell and taste of bacon rather repugnant, but there are a lot of people who really enjoy it, and I don't feel the need to criticize them for it. Why should it be any different with text editors?

alexeiz 9y ago

Trigger warning: the author is a Vim apologist/Emacs denier. /s

thedonkeycometh 9y ago

I don't think Atom is meant to open huge files, its meant for web development work where files are relatively short, and work is split up. So, i guess they don't have a test plan for large files, so they don't deliver something that can handle them, basically because its not meant to. And i'm ok with that. It gives me more than Vim.

pjmlp 9y ago

I just realized even Eclipse uses less memory than Atom.

amai 9y ago

I use IntelliJ IDEA. Everything else is for kids.

FullMtlAlcoholc 9y ago

These types of articles are little, if anything, more than pure fanboy-ism that is littered with hyperbolic claims. I'm running a 2013 Macbook pro w/ 8 GB of RAM, the Intel Iris graphic card, sttached to two external, stacked Ultra wide HD monitors(sometimes a 3rd 1080p in portrait). The only "upgrade" it has received is an extra SSD installed after I removed the optical drive. You would be insulted if, as a dev, a company gave you this as a workstation in 2017. Currently, I am running 8 electron apps(Slack, Discord, Headset, kiwi for Gmail, Insomnia as a GraphQL client, Visual Studio Code, Hyper as my terminal emulator, Spotify. When I feel like being unproductive, I open Pocket and push the total to 9) Bartender manages another dozen+ apps. Oh, and I also have open Chrome, Chrome Canary, Firefox Nightly, and Opera Neon. Chrome is running with 60 or so enabled extensions, Firefox has another 15 active add ons. And between all the browsers, I usually have around 75 open tabs, 18 or so sre running video or some other resource intrnsive media.As well as the occasional Linux VM. Iused to run the McAfee Global Threat map animation as a live background, but that was a little too much. Depending on what Im working on, Im usually running at least 4 or 5 servers. none that have to deal with huge amoubts of data, as id usually just provision cloud resources for that. Did I mention my 2013 8 GB MacBook handles this with ease? If I had a more powerful workstation, it would nit make me any more productive. I type at around 100-110 wpm and a more powerful machine wouldnt allow me to interface faster. So, when ornery devs violate the DRY principle on every single HN thread that is tangentially related to electron and trash it with an exuberance that would make McCarthy proud, I wonder, why? I imagine most have more powerful workstations than my own. I understand it from the perspective of those who have hundreds or thousands of tabs open (Around 30 or do open tabs causes cognitive overload for me and refuces productivity the more i have open.) I did have issues when running Atom and trying to open 30MB log and JSON files, but I wiuld also usually have 4 or more open projects. Ive since moved to VSCode after a year of apprehension due to having to give up ny many atom extensions, without looking back It doesnt sound like the author is doing anything that complex. There is no way that it takes minutes to open a 6MB log file, especially if using the newer version of atom. The idea that electron brings yoyr system to a crawl is simply not true, especially one app(unless its Atom). Electron apps work. The performance benefits of native apps are negligible on my productivity . And, usually, their aesthetics are a hindrance as I like ny apps to be visually appealing. All the other cross-platform solutions almost always look like crap. But this is only important if one values those particular aesthetics of which i speak. So, the attacks remind me of the discussion of artificial benchmarks comparing gpus or game consoles... immaterial and irrelevant to actual usage. Its an argument of pitentials and thereoticals never achieved. Especially for a freaking web developer. Even if you disagree with me, these threads are trash because nothing new or original is said. Just the complaints about the "kids these days" from a small, but extremely vocal minority whose comments are in stark contrast to the threads overall karma. Oh, and if If you're working out of emacs, electron apps are not for you.