5 ms·
Seeing as quite a few people here are complaining about the performance of Atom, I thought I'd give it a try see if there's anything to it. Cloned the 'Phaser'
by hacker_9 11y ago
Seeing as quite a few people here are complaining about the performance of Atom, I thought I'd give it a try see if there's anything to it. Cloned the 'Phaser' javascript game engine repo off GitHub and went through a few files (each with 500-1000 LOC), did some editing and... didn't have a single problem with performance.
I can only imagine that you and the other complainers are running older computers that can't keep up, or you've got a load of other programs running and your PC is having to use virtual memory. I thought it strange that Atom wouldn't focus on performance if it were such a problem as is being made out, but it seems that this is just the case for the vocal minority once again.
- mrcwinn 11y agoNope, completely wrong. I have a 32GB i7-4790K at around 4Ghz or so, and Atom is a complete dog. The painful truth is that a webview is never going to beat a native app at this kind of task. It's not a vocal minority. Atom is painful to use compared to, say, Sublime.
- 13years 11y agoI suspect that both are right. Some people are having issues and others are not. I don't seem to have any lag at all when typing even with multi megabyte size files. Maybe you could give some more details into exactly what actions were slow for you and what types of files you were editing. Actually, thanks to innovations in Mozilla's servo, the web may actually become faster than native.
- hacker_9 11y agoYou expect me to believe that with those specs Atom really runs like a 'complete dog'? The fact you also mention Sublime too really just tells me that your opinion was biased from the start. Finally, JIT compiled languages can be just as fast as native, simply because they can optimise to your hardware specs. You are getting mixed up as to why things are the way they are; JavaScript is a dynamically typed language, so the engine doesn't know AOT what types have what members, so this can cause a slow down compared to statically typed languages. BUT any JavaScript engine worth it's salt quickly figures the stuff out on startup so it's not a problem, as long as you don't use too many dynamic tricks that it can't optimise.
- drylight 11y agoYou should believe them and others on here. Atom is slow. No way around it. If you or others say that it's fine, then you're suffering from Stockholm syndrome, having been taken in to the cult of Atom.
- hacker_9 11y agoDid you not read my original post? I only just downloaded Atom for the first time.
- pyre 11y agoSeems to me like you're suffering from "I can't replicate it therefore it does not exist and everybody else is either lying to me or a complete idiot." You haven't actually called anyone out as liars or idiots, but your lack of belief of what they are communicating to you and the tone (from what I can gather) of your responses speaks for itself (whether or not that was your actual intention).
- spdustin 11y agoSo, no "real world" assortment of plugins for today's multilingual developer? Is that a valid assumption?
- azinman2 11y agoI'm just starting to use it today on a large code base, and it's been fine. Only have vim and go-plus plugins installed. I would guess plugins are what's slowing most.
- brazzledazzle 11y ago>If you or others say that it's fine, then you're suffering from Stockholm syndrome, having been taken in to the cult of Atom. Can we please stop accusing each other of malicious intent? I can't believe there are people on both sides of this argument that can't see that the other could have a different experience.
- yAnonymous 11y ago
- yAnonymous 11y agoSpeak for yourself. I haven't had any performance problems with Atom for quite some time with similar hardware.
- deleted 11y ago[deleted]
- riscy 11y ago> went through a few files (each with 500-1000 LOC), did some editing and... didn't have a single problem with performance. Pfft, 1000 lines of code? If Atom couldn't handle tiny files like that, you couldn't even call it an editor. Try working with a 10-20k+ line file (very common for me when looking at compiler output) and your heart will skip a beat when you realize that you had unsaved changes in another file before opening that file, because the whole program locks up for about 5 seconds trying to apply highlighting. I have to use sublime text for those files and watch where I click in Atom because of this. I'm using a very recent quad core i7 MBP with 16GB ram and an SSD, absolutely not my computer.
- hacker_9 11y agoOk sure, I opened up a 1000 SLOC file and copied until it was a 20,000 SLOC file, and performance was still fine. So I made it a 60,000 SLOC file. This time there was a small drop in perf as the editor caught up then it was fine again (not sluggish at all when editing the file). Are you taking this compiler log from a remote build server? AS in that case it's your network that is the bottleneck as the file is copied to your computer, which could be causing the lock up. Note: I'm using a 4790k 4ghz with 8gb RAM.
- riscy 11y agoNo, the file is not on a network; I don't get why you are in such disbelief... HN complains about a lot of things, but this is pretty cut and dry. I just opened a 2.4MB, 28425 line file containing LLVM IR, and it locks up just scrolling through the file, and the highlighter totally gave up and none of it is colored no matter how many times I try to get it to highlight it. Cutting it down to 5k lines gets me highlighting.
- pyre 11y agoNo! You must be lying! I just opened a file and experienced none of that. Therefore it is patently impossible for you to be experiencing what you say you are! /s Didn't we get enough of this BS in the era where people were "victim-blaming" over BSODs in Windows because "I've never had a BSOD and I've been running Windows for years?"