3 ms·

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

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.