Crashes and huge loading times when opening minified files


#1

Hey Guys,

Problem

I would love to use Atom as my main editor but it keeps crashing or loading for like 2 minutes when I open a minified file. I need to check my build.js often because I try to optimize my building tasks.

Any tips on that one?

My System:

  • Windows 8.1
  • 8 GB Kingston DDR3 RAM
  • AMD Phenom X4 625 4x3.0 GHz
  • 2x 500 GB Samsung HDD

#2

How big is your minified file?

There is a change coming in the next release, which is expected to dramatically improve large file handling.


#3

@batjko my files are around 20 - 100 kb

main.js: 21 KB
vendor.js: 118 KB


#4

It’ll be the length of the line then, since minified files are all without line breaks.
It’s been an issue for some time and it has just been closed. The change will be included in the next release (or if you built it from master, now).


#5

The issue still exists with 1.0.2 version (if i click on the jquery minified file by mistake my editor will 100% crash…), it’s sad they restricted publication about this issue on github, because they look to think it’s fine now and it is obviously not :’)…


#6

The issue that @batjko linked is closed with the note that the solution “covers the 80% case”, which is a specific acknowledgement that the issue isn’t completely fixed. But the bug above had outlived its usefulness because it was just a generic idea … and specific scenarios need to be addressed. Like this one that covers the exact issue you’re complaining about:

Which is still open. Again, an acknowledgement that it isn’t fixed.

Did you have any new information that you wanted to add @3ffy? Perhaps some helpful information you gathered to help characterize the issue so it can be fixed faster?


#7

[quote=“leedohm, post:6, topic:17523”]
Did you have any new information that you wanted to add @3ffy? Perhaps some helpful information you gathered to help characterize the issue so it can be fixed faster?[/quote]

In fact i don’t have a “coding” solution, but i got a simple one in mind to cover 15% of the 20%… Since the most part of problems come from minified files (in my case *.min.js ones) it would be nice to add a list of extensions as a setting of the plugin handling the colorization, with the aim to don’t colorize them.

Even if the memory problem is fixed, i think this param could be usefull, i love the idea to earn some ram/cpu with files who never will get any use of colorization (like libs as jquery).


#8

That’s actually a good point.
But identifying these isn’t as straight-forward as one would hope. There are packages and configs in the wild that will ‘un-minify’ your .min.js files, for example. And then you’d still want proper syntax highlighting, despite the filename not having changed.


#9

I actually suggested almost this exact solution. (Though I suggested just checking to see if the percentage of whitespace was below a certain threshold and assuming that it was minified if so.) The problem is that colorization isn’t the only thing that is causing the issue. Just really long lines in general are a problem, whether colorized or not.


#10

Probably the best temporary solution i can imagine :slight_smile:


#11

Any update on this? I’m forced to use Sublime for a couple of projects solely due to this issue. Also it really sucks when I accidentally click on a minified file in the tree and the whole editor crashes.


#12

Is there a solution, yet? It’s really annoying to be forced to restart Atom almost every time I accidently open a file that contains minified JS code.


#13

This still seems to be an issue. Atom 1.5 crashed 3 times for me today when I accidentally opened a 10k minified JavaScript file. The same file un-minified with line breaks in situ opens just fine. I’m running an 16Mb MBP, so no shortage of poke.

I’ve had to go back to Sublime, but I don’t like it as much anymore.


#14

This is still an issue with 1.6.2.

This is my first day using Atom and it’s been frozen more than not. It looks really awesome, though.


#15

Still an issue with 1.7.3 - not just minified files but files with lots of lines of code, just opened one with around 7,000 lines of code and it hangs horribly :frowning:


#16

Still an issue with 1.10.2 :frowning:


#17

Even though I run across this issue so often, I cannot even think of leaving Atom. Of course it has become 2nd nature that when I accidentally click on something like jquery, or some other 20-100kb file where I lose functionality, I close Atom, and start again. It’s 3-4 seconds of inconvenience, but thanks to auto-save, no harm, no foul.

To attempt to offer some insight, I’m curious why the file has to be completely loaded in the immediate view, especially when the size is problematic. I want to say that systems like CodeMirror only run syntax highlighting on the viewable area, and stream the rest when in view, instead of trying to run everything through the tokenizer all at once (Please correct me if I’m wrong about this). I’m sorry, I really do not know enough about Atom’s viewer, but can anything like this happen, at least with certain sized files?

I have also noticed that it depends on memory. Sometimes opening a minified file, or jquery file doesn’t cause any issues, but if accidentally hit more than one during this time, it’s game over. The point being that at some point Atom can handle these, but I’m guessing this is dependent on how long I have had Atom open, and how many files the view has seen causing a fluctuation in the current memory usage. I don’t know, but I thought I would at least share.


#18

Would love to see some resolution on this…it definitely interrupts my dev flow, especially when I actually NEED to look at the minified file


#19

@jazanne You’re in luck! A fix was added to v1.15 … check out the release blog post for details.


#20

Ahh I can’t believe I missed that! Thanks. updating asap.