Why I Still Use Vim • Hacker News Board

Re: Why I Still Use Vim

#151

Post by alkonaut » Wed, Aug 23, 2017, 12:52 PM UTC

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?

Re: Why I Still Use Vim

#152

Post by willvarfar » Wed, Aug 23, 2017, 12:54 PM UTC

bigato wrote: post #139

willvarfar wrote: post #95

Earlier quoted context omitted.

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.

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.

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

Re: Why I Still Use Vim

#153

Post by JoshMnem » Wed, Aug 23, 2017, 12:59 PM UTC

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

Re: Why I Still Use Vim

#154

Post by zelos » Wed, Aug 23, 2017, 1:00 PM UTC

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.

Re: Why I Still Use Vim

#155

Post by nonsince » Wed, Aug 23, 2017, 1:00 PM UTC

alkonaut wrote: post #151

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,…

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

Re: Why I Still Use Vim

#156

Post by dspillett » Wed, Aug 23, 2017, 1:01 PM UTC

nothrabannosir wrote: post #8

dspillett wrote: post #3

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?

That's the first point of the article. Well before the titular 6MB file.

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

Re: Why I Still Use Vim

#157

Post by thousande » Wed, Aug 23, 2017, 1:01 PM UTC

nnq wrote: post #76

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!

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

https://programmingpodcasts.com/episode/javascript-jabber/24...

https://programmingpodcasts.com/episode/javascript-jabber/19...

https://programmingpodcasts.com/episode/ms-dev-show/powershe...

https://programmingpodcasts.com/episode/adventures-in-angula...

Re: Why I Still Use Vim

#158

Post by wolco » Wed, Aug 23, 2017, 1:01 PM UTC

Klathmon wrote: post #82

nnq wrote: post #71

Earlier quoted context omitted.

Being electron/browser based is not and excuse for such horrific resource usage ... Visual Studio Code is also electron based and it's extremely lightweight (ram) and responsive on even the most underpowered machines I've ran it on. The problem is getting people that only have experience writing web apps to develop what is practically an IDE ... The good part is that this will teach frontend web developers a lot of t…

VS Code fairs quite similar to Atom in many tests in the linked article. But it does that by restricting what plugins can and can't do, and by integrating a large number of the functionality itself. I prefer to have the choice of multiple plugins each with their own tradeoffs, so I sacrafice some speed for it, but that choice can more than make up for it in many cases. And as for you claiming that web developers shou…

I hear a lot of talk about vs code. Tried it the other day was not impressed.

For a full ide webstorm/phpstorm seems nicer but slower to load. Sublime text editor much faster. Vim much more portable. I even found dreamweaver 5 to have more features, (editing single files over sftp, accurate visual preview).

Why is everyone moving to vscode? Is it a visual studio familiar feelings type thing or does it offer things I've missed in my limited preview.

Re: Why I Still Use Vim

#159

Post by Klathmon » Wed, Aug 23, 2017, 1:08 PM UTC

rootlocus wrote: post #101

Klathmon wrote: post #61

Earlier quoted context omitted.

I own a license and use IntelliJ's tools a lot still. Whenever I jump into Java code they are the gold standard! But when I'm working on web code, Atom runs circles around WebStorm.

> Atom runs circles around WebStorm. Because it can show you a preview of the page? Because, as far as code indexing is concerned, Atom doesn't do a very good job at all.

Well yeah, and all the other things that I like about it.

And as for code indexing, Atom doesn't do much of it at all out of the box. Everything is in plugins (by design). So it can use the full abilities of TypeScript or Flow if you add those plugins, or it can just use TernJS, or it can offer simple string-matching autocomplete.

It does as good of a job as what you plug into it does, as all it really does at the core is display text, and give a plugin interface.

Re: Why I Still Use Vim

#160

Post by alkonaut » Wed, Aug 23, 2017, 1:09 PM UTC

nonsince wrote: post #155

alkonaut wrote: post #151

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,…

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 w…

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