New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Files with large extremely long lines cause hangs #979

Closed
bnferguson opened this Issue Oct 16, 2013 · 70 comments

Comments

Projects
None yet
@bnferguson

bnferguson commented Oct 16, 2013

May be a known issue, but files with large embedded images such as github's public/enterprise/maintenance.html will often cause Atom to freeze (MacVim actually struggles as well).

Seems some of them (github's public/maintenance.html for instance) work fine when in soft wrap mode, or until you move your cursor to the long line when out of soft wrap.

@mcolyer

This comment has been minimized.

Contributor

mcolyer commented Oct 21, 2013

This should be fixed in the v32 release now that #1001 is merged.

@mcolyer mcolyer closed this Oct 21, 2013

@bnferguson

This comment has been minimized.

bnferguson commented Oct 22, 2013

Ran in to it freezing upon trying to open public/enterprise/maintenance.html with a master build this morning. May be a different problem there though. Won't even open.

@probablycorey

This comment has been minimized.

Member

probablycorey commented Oct 22, 2013

menubar

Can you tell me the sha you see under the Atom menu (like in the picture above)

@probablycorey probablycorey reopened this Oct 22, 2013

@bnferguson

This comment has been minimized.

bnferguson commented Oct 22, 2013

Yup! 4132cdd

@bnferguson

This comment has been minimized.

bnferguson commented Oct 22, 2013

(I rebuilt and tried it again in case I missed a commit, thus the really new sha)

@probablycorey

This comment has been minimized.

Member

probablycorey commented Oct 29, 2013

@bnferguson Is this freezing when you open public/enterprise/maintenance.html. If so, could you download screenhero so I can try and debug it on your machine (at your convenience)

@bnferguson

This comment has been minimized.

bnferguson commented Nov 1, 2013

Yup! Still an issue. Just had it lock up in a fresh master build. Downloading screen hero. Later this afternoon or sometime next week should work fine for me.

@izuzak

This comment has been minimized.

Member

izuzak commented Mar 31, 2014

Another report via support/612cacb6b6fa11e384554e10b2ee9be5

Opening files are really really slow in 0.79.0. It freezes the whole UI while trying to open the file.
...
I think I have narrowed it down to what is causing it exactly. It appears to happen on files with a really really long line. I have attached a .js file that constantly causes the issue. I believe it is the one line length issue, because I have other compressed .min.js files that cause the same issue because they are all on one line.

@izuzak

This comment has been minimized.

Member

izuzak commented Apr 20, 2014

via support/90240870c84811e39e74c419500d2fe2

The editor still lags when opening large js files, large minified files etc.
It's a very small file ~130 KB. (See file attached) Although when i open it for the first time after boot, it takes around ~2s to load, which actually is not giving me any issue but as i am used to Sublime Text, which is far more speedy in this regard to make the comparison.

I just tried playing with minified jQuery and this is the behavior I observed:

  • when soft wrap is turned off, navigating long lines is very slow (e.g. it takes a few seconds from when I click somewhere within a line to when the cursor shows up)
  • when soft wrap is turned on, navigating is fast, but editing long lines is still noticeably slow (e.g. it takes a second from when I press backspace to when a character is deleted)
  • I didn't notice any abnormal slowness when opening the file
@BrandonDusseau

This comment has been minimized.

BrandonDusseau commented Jun 5, 2014

This issue still exists in 0.100.0. I'm getting a hang on a minified CSS file that consists of only one line with over 237,000 characters.

@garand

This comment has been minimized.

garand commented Jun 5, 2014

Same here. I had the issue when editing CSS attributes that had a data encoded image in them. Very long lines. Removing them put everything back to normal.

@ilanbiala

This comment has been minimized.

ilanbiala commented Sep 10, 2014

How does Atom handle files? Is it an array of strings, a buffer, or something else?

@kevinsawicki

This comment has been minimized.

Member

kevinsawicki commented Sep 10, 2014

How does Atom handle files? Is it an array of strings, a buffer, or something else?

An array of strings, one for each line in the file.

@ilanbiala

This comment has been minimized.

ilanbiala commented Sep 10, 2014

@kevinsawicki does that offer any benefits over storing it as a buffer? Maybe you can link me to some of the code that handles this in Atom.

I'm thinking that if we can speed up file open time, then we can add in a nice improvement for searching through files. When someone presses cmd+t and goes through the files, the file should already show up in a new tab that isn't in the tab bar yet. If the user does select a file, then a new tab is created and almost no wait time should occur. For this and a lot of other useful improvements to happen though, almost any file - no matter the size - has to be opened quickly.

@benogle

This comment has been minimized.

@benogle benogle referenced this issue Sep 30, 2014

Closed

Atom 1.0 #3684

18 of 25 tasks complete
@rakkarage

This comment has been minimized.

rakkarage commented Oct 13, 2014

this 1 line (131090 characters long) of yaml causes the same problem i think
shows fine as text
http://pastebin.com/Cx3zy9fm

@derwaldgeist

This comment has been minimized.

derwaldgeist commented Aug 29, 2015

Bump. I'm using a database prefiller skript that uses base64-coded images to store them in the database. It's only 3 images, but Atom editor hangs on loading. Even worse, after "killing" the editor using the "hang" dialog, the tree-view is missing.

@doug-orchard

This comment has been minimized.

doug-orchard commented Sep 9, 2015

Loading a uglified react.js file created by browserify... it hangs. on MacAir, 4Gb RAM.

@Dbuggerx

This comment has been minimized.

Dbuggerx commented Sep 11, 2015

Same here. I've optimized my AMD (RequireJS) modules, and the long lined "uglified" file makes Atom (1.0.3) freeze.

@dinukadesilva

This comment has been minimized.

dinukadesilva commented Sep 12, 2015

Hi , I would like to contribute to github atom. Please help me how can I join with the discussion groups. It'l be a good experience for me to join with Github also while studying since I have experience in Opensource for some time.

@timdp

This comment has been minimized.

timdp commented Sep 12, 2015

I fully realize that this is not an easy one to fix, but at the same time, it's quite awkward when I convince another colleague to use Atom and then it hangs indefinitely when they open a random file.

From the looks of it, an intermediate solution would be to limit the line length at which the RE parser kicks in. After all, disabling syntax highlighting and linting is a lot better than going completely unresponsive. My gut feeling says that this would be a relatively straightforward patch. Any chance of getting it in for the time being?

@shanalikhan

This comment has been minimized.

shanalikhan commented Sep 12, 2015

I agree with @timdp
I convinced many programmers to atom but really ashamed off when they randomly opened some file and it hanged every single time.
They all moved to visual studio code
I love atom therefore always looking discussion witha hope that they will make it faster else i will move to visual studio code.

@doug-orchard

This comment has been minimized.

doug-orchard commented Sep 12, 2015

A solution I just discovered currently involves adding a .jshintignore to the app root with 'public/jquery.js' (or whatever the file is causing you issues) if you are running the jsHint package. Still a small hint of delay but i can say, no more messages asking to close the window or wait. Also turning on in the jsHint package, only run when .jshintconfig is found ( just find any default file out there ).

@timdp

This comment has been minimized.

timdp commented Sep 12, 2015

Also, @hokein did some great work profiling typical invocations earlier in this thread. Below the _findNextMatchSync function that he identified as the culprit, there's a _findNextMatch that is presumably async. Wouldn't it also be possible to use that one? Or would that just slow down linting like crazy and become a nightmare to maintain?

@CrazyPython

This comment has been minimized.

CrazyPython commented Oct 5, 2015

Works on OSX and in the browser too. I don't know why long lines cause such a problem. This freezes my entire browser and pretty much prevents me from doing anything else.

@derwaldgeist

This comment has been minimized.

derwaldgeist commented Oct 6, 2015

@timdp Yes, I'd also prefer having no linting over having to kill the whole editor...

@CrazyPython

This comment has been minimized.

CrazyPython commented Oct 6, 2015

@derwaldgeist I'd prefer having no listing than having to kill my entire browser... (with not-exactly-restorable data)

@skyrpex

This comment has been minimized.

skyrpex commented Oct 6, 2015

👍 for no linting in this case

@CrazyPython

This comment has been minimized.

CrazyPython commented Oct 8, 2015

I think there should be a disable lint functionality in web Atom; or perhaps a persistent setting in HTML5 web storage.

@maxbrunsfeld

This comment has been minimized.

Contributor

maxbrunsfeld commented Oct 8, 2015

I don't think 'linting' has anything to do with this. Atom does not provide linting; it is provided by a third party package: https://github.com/atomlinter/linter. If you want to disable syntax highlighting, select Plain Text from the Grammar Selector.

@CrazyPython

This comment has been minimized.

CrazyPython commented Oct 14, 2015

I hope this is fixed soon. I pretty much can't edit HTML files on GitHub. On slow computers, it freezes me for 5 seconds every time I type a character. On my MBA, it freezes when I type a few characters I type, and then I have to close the browser. Is there a way to change atom into a raw text editor?

Soft wrap or not, this issue has been dancing around for two years. I'm going to try and profile it and make a pull request (I've never seen a single line of Atom code... shouldn't this be at the top of the list?)

@ghost

This comment has been minimized.

ghost commented Oct 26, 2015

Just to add,
working with large JSON files this is also causing me issues,
currently cannot open atom at all,
have deleted the file which caused this and still cannot open atom.

@yihaa5

This comment has been minimized.

yihaa5 commented Oct 26, 2015

I'm already switched to Notepad++ . Didn't see much progression for this commonly required fix. Kinda dissappointed.
Thanks afterall for the Effort of building this editor.

@skyrpex

This comment has been minimized.

skyrpex commented Oct 26, 2015

I hate to recognize it, but I switched back to Sublime Text again...

On Mon, 26 Oct 2015 at 13:55 yihaa5 notifications@github.com wrote:

I'm already switched to Notepad++ . Didn't see much progression for this
commonly required fix. Kinda dissappointed.
Thanks afterall for the Effort of building this editor.


Reply to this email directly or view it on GitHub
#979 (comment).

@shanalikhan

This comment has been minimized.

shanalikhan commented Oct 26, 2015

Well i have switched to visual studio code ! Already
Thanks developers afterall for atom !

@thomasjo

This comment has been minimized.

Member

thomasjo commented Oct 26, 2015

I'm locking this thread for the time being — there's no value in notifying 35+ people about switching to another editor. Yes, this is definitely something that should be addressed (and it has to a certain extent), and is being worked on indirectly even though it might not be apparent. Increasing the performance of Atom is one of the top priorities.

@atom atom locked and limited conversation to collaborators Oct 26, 2015

@50Wliu

This comment has been minimized.

Member

50Wliu commented Feb 15, 2017

Atom should be able to open files with very large lines starting with Atom 1.16.0.

@maxbrunsfeld

This comment has been minimized.

Contributor

maxbrunsfeld commented Feb 17, 2017

We decided to back-port this fix to the current beta release, so it's available today in Atom 1.15.0-beta3.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.