Workspace hangs on open if large file is left open


I’m running Ubuntu Mate 16.04 with atom 1.32.2 x64.

I run atom by opening up a terminal, changing to the proper directory, and running atom .. I work with several workspaces and this has been working fine. However, one workspace is having issues all of a sudden. Using the atom . command will open atom, but it just hangs and doesn’t fully load.

I moved the ~/.atom directory to ~/.atom2 to back it up and start from a fresh configuration. That didn’t work, although it did improve. Before it would only show one file in the tab bar, but without it’s filename. Now it’s showing two files with their names. However, atom still hangs. I can’t do anything in the editor and eventually have to force quit.

I am surprised that two files are being loaded after clearing the config directory. Where is this setting being stored? I don’t see any atom related files in the directory. I feel like if I can clear these files it’ll work.

It just hit me to move my workspace to a temporary location, create an empty directory, open atom so no files exist, close atom, move my workspace back, and open atom again. This worked. No files are loaded and I can see my project and all its files.

One of the files I had open is roughly 8K lines. If I leave this file open and close atom it’ll hang on start again. Even if I choose Keep Waiting multiple times it never loads. I can see the files, and the code of the last open file, but the editor hangs. If I don’t leave this file open I can open my workspace fine. Note I can load this file just fine when I’m working in atom. It’s only on startup that it hangs. What exactly is going on?

Also, I’m still wondering, where the file list is being stored at since it’s not in ~/.atom. Is there any other configuration stored elsewhere?

edit: Just to provide more information on the file, it’s only 481K. So it’s not large in file size, just in the amount of lines. It’s a header file with a ton of defines, each with a bunch of translations.


I’m not sure what you mean with file list, is it the tree-view pane on the left side? Is your project made of those two files?

Atom stores its window state in the AtomEnvironments IndexedDB, you can view (or edit) it through the developer tools.


1 Like

Sorry for the confusion. By file list I was referring to the tab bar of open files. My project has a lot more files in the tree view on the side bar. The issue happens when the one file is left open and atom tries to open it on startup.


I don’t know where the storage is for Linux machines, but session memory is stored separately from config settings. You can clear Atom’s session memory with the command atom --clear-window-state.

What exactly is going on?

JavaScript is not a good language for doing all of the things that Atom tries to do at once. Large files, even files that only have a large number of lines (or, before the parser hard cap was put in place, files with a single very long line) can eat up enough processing power that the rest of it slows way down, sometimes to the point of becoming completely unresponsive. Things have gotten better and they will continue to improve, but I imagine that some form of this behavior is a natural symptom of using JS for things it wasn’t meant to do.

1 Like

Using atom --clear-window-state . works nicely. A lot more convenient than going into the database. Definitely will help if I forget to close that file.

Interesting information. Makes me wonder why nothing has been done to make things usable. Things such as “if lines > x, open it as plain text with no syntax highlighting”. While not optimal in terms of a pretty display, at least it’s usable until it’s optimized enough to handle those types of files properly (assuming atom can handle plain text). Even checks before loading would work such as “if file x has lines > y, don’t load it until atom is fully loaded and user clicks on that tab”. That’s something Firefox does when loading the previous session (I think it’s optional). It’ll start quicker because it’s only loading one tab. The others don’t get loaded until you click on them.


This is what happens when Atom is already open and you open a large file. I don’t know why it’s not working in your case, but there are so many things going on during startup and they’re all in the same process, so (because it’s JavaScript) they all run the chance of contributing to the program hanging up.

Even checks before loading would work such as “if file x has lines > y, don’t load it until atom is fully loaded and user clicks on that tab”.

That sounds promising, but I don’t have knowledge of exactly how that would be implemented. It might be worth checking the GitHub issues to see if anyone has suggested it.

1 Like

Hmm. So the plain text loading is already a feature? The file with 8K lines loads when atom is open, but it’s not plain text. It has the syntax highlighting (it’s a C header) and it’s sluggish when navigating it. I imagine if it was loaded as plain text the performance would be much better.

That second suggestion would take a little bit of work. It wouldn’t be impossible, but not as easy as disabling syntax highlighting. You’d have to change the startup to load only one tab and not the others. And you’d have to change the UI to load the other tabs when clicked if they aren’t loaded as I’m sure the current state is assuming any tab is already loaded.


I believe that Atom tries to read all open files at once regardless of which ones are actually visible. That would probably have to be changed.

1 Like