I used Atom for over a year then switched to Sublime Text because of Atom's inability to open large files and because of its slowness when doing things like highlighting as you type while using Find in a large file.

I think the problem is simply that their stack handicaps them severely in this respect. I need my text editor to be able to handle large files and to be extremely fast.

I used to have this problem with Atom a long time ago. It is slow for huge files. I switched to visual studio code for this reason, despite being on the same shell, vscode is way faster than atom

They added an option at "Settings > Core" to "Warn before opening files larger than this number of megabytes". I don't use Atom at all, but after so much discussion about this issue I don't think there is a better solution. This clearly shows the difference in performance of a web-based text editor versus one built on top of a native UI library, but people prefer to sacrifice that performance for the nice interface and the extensibility, I suppose that many of these happy Atom users don't work on huge projects like some of us do, Atom works okay for what it offers.

I don't think "huge projects" factors into it at all, no reasonable source file should ever come anywhere close to the Atom file size limit. If you have 13MB source files you have more serious problems than your choice of text editor.

The kind of files that choke Atom are large data files that there are usually better/different tools for, that have very different requirements from code editing. And that has little to do with the relative huge-ness of your projects.

I regularly deal with this problem because my use case demands viewing huge JSON files of size > 20 MB with lines of text that can exceed tens of thousands of characters (WKB polygons). You can argue that Atom is not suited to this particular use-case (and I would agree), but what can we do to make it better? I'm very curious as to the specific aspects of Electron/Atom that make this kind of operation slow and would be willing to contribute to make it faster.

It's already been proven that Javascript can be fast for this kind of thing. So there is something in the infrastructure that can be improved.

It's a text editor, not a source code editor. Log files can be that big, as well as a bunch of other things, like csv's.

It's not unusual to have things like compilers that generate big intermediate C files. Editors programmed using same technologies handled them just fine decades ago.

It's not only huge files that it's chocking on.

Last year I was working on a game demo under time constraints and to cut a corner I base64 encoded a bitmap font. Every time I opened that 32KB file it began to slow down because that one big line.

That being said I still use atom daily but not one big files or ones that contain big lines.

Visual studio code is a web based text editor is it not?

Specifically based on Electron, Atom's own framework: http://electron.atom.io/

What is VS Code doing differently to make it so performant? Is it simply less extendible?

My understanding is that the editor portion of it was created specifically for Visual Studio Online and it had a smart and dedicated team (acquire hire maybe?) working on it.

They have released the core part of VSCode as a node package called Monaco.

I have the same problem, as I often need to inspect large text files resulting from experimental measurements or fluid dynamics simulations.

Use Atom for source code and another editor for large text files (such as logs).

Yup, every time I accidentaly open a minified file, it hangs for a minute.

Especially problematic as things turn up in search results, so you click on them, then realize it's a build file and you can go get a coffee

That can be problematic for reasons other than size. Usually minified files will not contain any newlines, meaning that not only is the file rather large, it is effectively all on a single line.

I've seen things like vim have problems with files like that, I think mostly from trying to syntax highlight the visible region.

When you code - use Atom.

When you need to edit data files or other huge files - don't use Atom.

This is a deal breaker for me. If other editors could handle remote filesystems as good as Atom I would have switched to something else perhaps VS Code. It is weird that Atom has been having this problem for so long and they don't seem to care about fixing it.