I think I have narrowed this issue down now. Earlier I had assumed this affects all files of certain size, since when I had run into this I was involved in a pr

I think I have narrowed this issue down now. Earlier I had assumed this affects all files of certain size, since when I had run into this I was involved in a project where I had to look at certain textual content (dumped out of DB as JSON). That content was generated by one of the in-house dump tools. I had a closer look at one of the files just now and now have a simple python script which consistently reproduces this issue with ST3. Here's the python script which generates a file which can then be opened in ST3 and timed. content = 'a' with open('content.txt', 'w') as f: for x in range(1, 18888789): f.write(content) It took me 39 seconds (consistently) to open it. The generated file size is less than 20MB. The problem appears to be that ST3 slows down while loading this file which just has 1 huge line. If I tweak that script to change the content from 'a' to 'a\n' to include a new line within the content, the generated file loads relatively quickly and in reasonable time (around 6 seconds for the 37MB odd file). I admit, this now I think can be considered a corner case but when I ran into this pretty frequently, I just assumed this happens with all files with such sizes. As for why I believed ST2 doesn't have this issue - I'm not sure anymore, because when I try these files now with ST2 it too behaves similarly. I no longer work on that project which generated these files so had it no been for this thread, I would never have bothered to dig deeper into this and would have just stuck with ST2 :)