Painfully slow buffer-update for large files

[ArekSredzki]

Problem description

If a large file is open in an atom editor window and it is reloaded for whatever reason, it will block the entire editor. This will happen for a painfully long time.

Very often I will have a large JSON file open and for one reason or another it will be reloaded, typically caused by a fs change, and the entire browser will be blocked for what is often a minute or more.

Today I finally performed a profile of the issue and nailed down the cause.
Here is the result for the reload of a relatively medium sized file (only ~6000 lines).

Suggested changes

Short term

Give the user the option to diff the file or simply forego the ability to undo the reload if the file is large.

• Reduces user frustration by eliminating unexpected behavior
• Retains functionality if one wants it
• Easy to implement, shouldn't take more than a couple LOC 👍

Long term

Somehow preserve undo-ability for massive files

Execution

Let me know if you like the sound of the short term solution, I'd be happy to implement it ASAP

[50Wliu]

@ArekSredzki Just to make sure: are these files located in a Git repository? If so, do the performance problems still happen if you move them into a non-Git repository?

[ArekSredzki]

@50Wliu The files are in a Git repository, however I just performed a test outside of any repos and the result was the same. The file I did it with was a bit bigger and the IDE is still blocked ten minutes later.

Looking through jsdiff's release notes, it sounds like this and many other issues have been resolved. I was about to submit a PR to rebase atom/jsdiff but I think the best action is to abolish it all together & just use the main branch kpdecker/jsdiff seeing as there is active development going on there, and absolutely none on the atom fork. Your thoughts?

[50Wliu]

@ArekSredzki That sounds great, especially if the line endings issue documented in @benogle's fork was fixed.

EDIT: Actually it seems like it has...no idea why we're using a horribly outdated fork then 😕.

[ArekSredzki]

@50Wliu Great! I'm so happy to hear that my troubles with this will soon be over! His commit seems to have been pulled into the main repo soon after the atom fork was made, so it's been fixed just the same there 👍 Any ideas as to when these changes would make it into the atom release?

[50Wliu]

@ArekSredzki It depends on when we switch to the main repo. If we're lucky it'll be out in Atom 1.7.0, if not Atom 1.8.0 or beyond. I'll go create a PR.