Tile Rendering PR makes atom open a 10MB file like a champ


Its time for removal of <2MB limit.

I have tested by copy-pasting 1MB file 11 times and With tiled rendering PR , which is merged to master : https://github.com/atom/atom/commit/4941229a1b26353ea5bb5c181f219698239f5e0b

Atom is rendering smoothly!

i am looking where is the limit and removing myself :slight_smile:


I think we should probably do a bit more testing than testing it on one file before removing such a limit.

How does Atom handle files with a large amount of tokens? What about lots of lines? Sparse / Character Heavy files? Does Atom fail gracefully or just explode?


So once the tiles are default and stable, re-testing the size limit will be the next step.
If it can then be removed, awesome.


You can help with testing , i had test the followings


  • [x] 11 MB file
  • [x] More than 100k char per line
  • [x] Compiled Javascript file (long line of true javascript tokens)
  • [x] Very long line of character
  • [x] Select word , Select Line , Select Multiple line , Select all


  • [ ] Reopen session with many tabs and one huge file.


Also how large selections behave, decorations, block folding and other operations on those large files.


I have tested Large selection , not block folding, Tested cut/ copy / paste too . They all work fine.


I’d prefer to see some more rigorous tests than just people fiddling with things before we pronounce it “fixed”. Here are some things I would want to see:

  • Different file sizes — 1MB, 10MB, 100MB, 500MB, 1GB, 5GB
  • File content — Plain text, Tokenized text
  • Operations — Folding, copy/paste, find-and-replace (especially things like converting from tabs to spaces and vice versa), markers, multiple cursors, scrolling

And include timings rather than “works fine”.

Also, I would prefer if we would stop saying things like “faster than Sublime”. This is sooooo subjective as to be meaningless. Because I know you probably mean scrolling and other in-editor performance, but Sublime still starts up faster than Atom and that is the main complaint people have coming over from Sublime. I would prefer that we stop comparing ourselves to subjective, wishy-washy standards and start reporting objective measures like the ones above.


I still have significant performance issues on occasion, most recently a 2MB/56K line (none of them longer than maybe 250 characters) XML file. It takes a few minutes to apply syntax highlighting, during which time the scroll bars don’t work. Oddly enough the minimap package actually makes it so I can scroll while highlighting is being applied and seems to make the buffer more responsive.

Once the loading is done, the editor periodically hangs. Text searches within the document are slow and it seems like as-you-type highlighting and result counting is done synchronously with key presses because the search field display lags behind my keypresses about linearly in time with result counts.


To be a little more clear @Astrophizz, @v3ss0n is talking about the absolute latest master build-from-source version. If you’re using a released version, you don’t have the performance fixes that @v3ss0n is talking about.


Ah, thanks! I look forward to that being released :smile:


Thanks . Yes i want to see those tested, Right now i got to remove <2MB limitation to test .

@Astrophizz You can use https://github.com/atom/atom/commit/4941229a1b26353ea5bb5c181f219698239f5e0b if you like to test.


I’d prefer to see some more rigorous tests than just people fiddling with things before we pronounce it “fixed”. Here are some things I would want to see:

Not asking to pronounce it fixed , but with tiled rendering it can render 2MB file very fine. up to 11MB smoothly. Its up to main dev for lifting that , for me i am patching myself so i can test bigger files.

I didn’t say it here, not in this thread .

Objective measures? why , i do not understand why my tests are objective. I was working and reporting directly to @as-cii who is maintainer of the PR . And also report here. I am not doing any wishy washy here i believe .


What does “works fine” mean in the number of milliseconds that it takes to scroll a 10MB file 100 lines?

I apologize for being harsh. I’ve done performance testing for a living. I am glad you’re excited for the progress Atom has made and I should let you be excited.


I admit i was excited because i was never able to open big files, well in my favorite opensource editors except vim or less. But with this tiled rendering of Atom , it let me do that beautifully in first time in many years.

Its ok , but i just that i never insult any editor or anyone , just testing and reporting what works , in excited tone , but not as a Fanboy.

Thats very good , would be very helpful. In my profession my employees does performance testing for my projects , so you can help me with advices for testing atom performance.

I really appreciate that kind of constructive stuff. We would be able to help after preparing my team for this weekend hackathon.


If it can do 5GB then I’ll pull my view-tail-large-file package and release a tail-file package.


To be fair, atom has evolved unbelievable on that matter in the past months. Right now my start up times (without compilation of new packages!) is always <1000ms, and that’s absolutely useable!

Even on windows! On OSX it’s closer to 800ms. And since then it has replaced sublime (I still have both installed but I can’t remember when I used sublime in the past 2 weeks).


Does Atom have a suite of performance tests, the way every release of Node.js has one? If not, then it certainly seems time to develop a suite of tests, to help get measurable, objective results.



There’s the benchmark suite: