4 ms·
The install size doesn't bother me personally (although my colleague's with newer Macbook Pro and smaller SSD may have an other opinion) but the speed of the ed
by glenndebacker 11y ago
The install size doesn't bother me personally (although my colleague's with newer Macbook Pro and smaller SSD may have an other opinion) but the speed of the editor is important for me.
It is fine for smaller simple files but I have had occasions that with some text files it can be really slow to a point that it is unworkable.
Last I was working on a HTML5 game and I copied the base64 encoded version of a font into my file that handled the assets and boy was that a bad idea. The preload.js was just 49KB but one big base64 encoded line made atom choke... Textwrangler or sublime didn't crimp on the same file and opened it in an instant.
Granted my Macbook Pro is old but a i7 with 8Gb RAM should be able to deal with these kind of situations.
- Klathmon 11y agoYeah atom has always had issues with files over a few kb that are all on the same line. If the file doesn't have any crazy long lines, i've had it handle 5mb+ files with no issues.
- PlzSnow 11y ago"i've had it handle 5mb+ files with no issues." Wow! It's so exciting living in the 1990s!
- Klathmon 11y agoOkay, if you want to be a dick about it. I've had it handle 5GB+ files with no issues. I've got a 6.3gb log file open in it right now.
- PlzSnow 11y agoTry doing a find/replace/syntax highlight/multiple cursor/anything productive. Actually don't, your computer will explode!
- Klathmon 11y agofind/replace works fine, and it's an XML file so syntax highlighting is working great (although it does take a few hundred ms to actually apply the syntax highlighting after a lot of scrolling) It did take about 2 seconds to load the file though, so you can make fun of that!
- kedean 11y agoOn a more constructive note, I've found that it does have significant problems with certain text structures, namely really long single lines. Just the other day I had to debug a json serializer, so my q&d solution was to copy the text out of the eclipse debugger, paste it into Atom (as it was already open), then find my way to the section I was looking for. After significant delays getting to the spot I needed with 'find', any use of the left and right arrows to navigate the text further was accompanied by a ~5 second delay per character. The same operation in Notepad++ went smooth as butter.
- Klathmon 11y agoI agree 100% I'm not sure specifically what it is, but it seems longer lines just wreck the performance. I've seen a few commits talking about fixing specific problems that have caused this in the past, leaving me to think that it's most likely either one or more of my plugins causing the issue, but i just haven't cared enough to look into it yet. Just like you I keep Notepad++ around for my "quick" needs (open a file for less than a minute) and for big files that aren't "code-ish" (they have long lines), and then atom is used for everything else.