Atom text editor 1.4 released
github.com
github.com
Here 100% would represent full usage of a CPU core:
BBEdit:
15 files open (various types/sizes)
76MB RAM
< 2% CPU
1 process
25MB app disk space
10 files open (various types/sizes)
169 RAM
< 2% CPU
1 process
27MB app disk space
1 small Markdown file open
> 1.2GB RAM !!!!!!
> 85% CPU
7 processes
205MB app disk space
I will spend a little time looking into why this is happening. I certainly could be related to some add-on package that I have installed, but I don't every recall seeing BBEdit or SublimeText behave so poorly with all of the customizations I have thrown at them.
Update: added disk space for base app. Even with a 500GB SSD, Atom would make me think about its value vs space usage.
Update 2: the system specs. 2011 MacBook Pro 13-inch, 2.3GHz i5, 500GB SSD, 16GB RAM, OS X 10.11.2
Update 3: performed a clean reinstall of Atom, removed all third party packages, removed preference files, disabled Markdown preview. Atom is still using over 80% cpu and greater than 1GB RAM with one short markdown file open
It makes sense within the context of the Atom dream: to make a completely customizable editor, down to the pixel.
But Emacs has almost the exact same dream: to make a completely customizable editor, down to the character-grid cell.
This one small difference gives it way more performance, without much loss in my opinion.
Atom is extremely bloated in every sense of the term. It's bloated in CPU, in memory usage, in files, in libraries, in dependencies, in overall performance, in everything.
All because it wants to be customizable on the pixel level, rather than the character level.
I wish a new editor would arise to actually complete with Emacs. I hate this piece of junk editor, but it works, and it gets the job done.
except one notorious bug when trying to open minified javascript files of hundred kB.
That's weird to have such a difference performance-wise between users, because it's based on chromium which does not suffer plateform specific performance drops I think.
Do you have issues with Google Chrome also ?
I think that's his point. To some people, like leejoramo, if their text editor is a resource hog then it is not running fine.
Edit: Just checked, after using Atom for two days straight it is currently occupying 80MB of ram. Anecdotally, the claim that Atom is a resource hog is actually wrong.
This is on Linux. Other than that, I would say performance is reasonable on all projects I've worked with (couple hundred files in a folder while actively editing a handful at a time).
How come Atom is slow for so many people? Visual Studio Code is based on Electron as well and doesn't seem to have that. I tried VSCode for TypeScript and it was very smooth, not as good as Pycharm for my usecase though
So microsoft did a great job. Issue is that there is a much smaller community, less plugins and I have mac so no other ms synergy for me.
That said, I am going to try ot again today. I liked it
VS Code isn't the fastest thing ever and uses more RAM than I'd like, but it definitely hits tolerable performance for me.
It's definitely the exception rather than the norm. I wish they'd publish something about writing efficient Electron apps.
Actually, it has been a few months since I last checked on VS Code, I guess I should give it a spin again.
For me the biggest problem here is the high CPU usage when the app should be idling. That KILLS battery life. I would not accept this behavior from high end video software, I certainly will not accept it from a text editor.
Following that the high RAM use can lead to swapping which will impact performance and battery live. As I said above after a clean install, and with just one short markdown file open, Atom is now using over 2GB RAM and Climbing. Fortunately, I have 16GB RAM on this system, otherwise I would already be swapping.
BBEdit and SublimeText never tax the CPU unless I am working with extremely large files, or doing search & replace on a huge number of files. I often will have 50 to 100 files open for days in these editors.
I like the evolving ecosystem of Atom, it now looks to be about on par with Sublime, and I can see that it will soon over take Sublime on that front. But it really need to get the resource utilization under control.
To be fair to Atom, I also tried installing it on a Mac Mini with an almost clean Mac OS X 10.11 installation. I had similar problems.
Neither does Atom for most users. It's not just n problem of «resource utilization», you're clearly facing a bug … Maybe you should consider submitting an issue (https://github.com/atom/atom/issues)
Again, I am see the issues on admittedly rather heavily customized workhorse MacBook (lots of Unix level tweets), AND on my stock Mac Mini. So I don't think this is a case isolated to just me.
The only time I get real lag on my system is when I'm opening a really, really large and minimized / mangled javascript file. Occasionally I get problems with the minimap or linters on very long files, but I have started regularly working with source files in the 5k - 10k lines range. I inherited and am refactoring and breaking down some monolithic stuff into more modular code, so there's a lot of tabbing around and copypasta in addition to regular coding, and atom's been responsive.
The thing I like about atom is that there's a pretty robust plugin ecosystem already.
For me, Atom idles at 0.5% CPU. 10 files open, 130MB of memory being consumed.
I'm fairly sensitive to slowness for an editor. Earlier versions of Atom had too much noticeable lag. Recently, though, it seems pretty performant.
Open a 1000 line json file. Most of the issues are on syntax highlighting. The editor has a very bad way of inplementing this, based on it always crashing or timing out.
Problem is fixed if sh is plaintext
The editor used to bottle neck, hang, and usually would just quit after being non-responsive.
This has been fixed. The editor would take ~45-60 seconds (I timed it when i logged the issue on github). It now takes ~3 seconds. Sublimetext comparatively, is a bit better at <3 seconds, atom takes about 3-5 seconds and shakes out the highlighting over another 1 or 2. In total, you can start working on the file in about 4 seconds which is a big improvement over never/1 minute.
Look at file io, socket io patterns.
I'm in the exact same boat. Other people tell me they like Atom and every single time I try to use it my system thinks I just set a vampire on the CPU.
189 opened buffers (4 terminal sessions, rest are mixture of Ruby, Clojure, Javascript and Elisp files)
< 1% CPU
2 processes (server + attached editor)
no idea about disk space probably around 100MBIt was more resource intensive than Visual Studio 2013 Community Edition lol.
Well, I kept digging and ultimately found a very long running issue thread[1] that mentioned having a .git directory in your home directory can cause high CPU.
Removing the three year old and accidentally created ~/.git directory and restarting Atom fixed the problem.
So now I will give Atom a deep new look.
Still, I am a bit perplexed, this is an issue that has been reported for nearly two years, and has not been fixed. I am not sure about the technical nature of the problem, but I think Atom, is trying to digest my entire 340GB home directory. Assuming that this is desired behavior, there should be at least a warning at launch about the issue. I am sure that MANY people have accidental ~/.git folders, and have a bad experience with Atom. At the vary least, it should not have taken me a couple hours of digging to find a solution buried in a GitHub issue.
While this fixes the issue on my MacBook, I am not sure about the Mac Mini, which I don't think will have a .git directory, but I will check later tonight.
[1] https://github.com/atom/atom/issues/3426#issuecomment-119780...
There's something seriously wrong with your system's compatibility with Atom.
Atom may never be as fast as a truly native client but it's perfectly usable now and is increasingly leaving the competition in the dust when it comes to features.
Have they switched from Coffeescript to JavaScript?
Kind of curious why they made that decision in the first place.
Oh, they are a Ruby shop. Right.
"Leaving the competition in the dust" sounds a bit like hyperbole. Can someone provide a better comparison?
Code completion? Multiple cursors? "Ace jump" ... navigation in general. I guess "precision editing" encompasses what I'm trying to say.
Can you please back this up with any benchmarks? 2 months ago when I tried VSC, though the UI and some features (git workflow) were really nice, performance was again a disappointment compared to Sublime. Having played with Electron myself it's obvious why performance is an issue with both Atom and VSC.
EDIT: s/flow/workflow
- Atom fairly regularly freezes on me -- probably once every two days such that I have to force kill it.
- It also is very very slow opening large files (+1M files), probably at least 5x slower than Sublime in that regards.
I love the drag/drop sidebar but If this update doesn't inprove the editor significantly, i will delete it.
The problem is that "best" is subjective. I think one could more accurately say that they're trying to develop an editor that is easily extensible with technologies familiar to many developers.
i.e. your perception of what they want Atom to be and the reality of what they want Atom to be are probably not the same.
My take? Revisit this in five years. I bet it'll be one of the richest ecosystems in software development. As one who has written Atom plugins (live unit testing w/ real-time feedback), I've never encountered such a developer experience until Atom.
Lets say if one of the main goals was to build a very easily extensible editor, one might still choose to build it on web technologies.
While I don't use atom, I can see the reasoning. Since I'm comfortable with webdev, the barrier to entry for extending atom is much lower compared to other newish editors.
* metrics: sends personal data to Google Analytics
* exception-reporting: sends personal data to bugsnag.com
Both are fine editors and I use both [Ubuntu versions] in different contexts. It's fantastic that both are open source. That's were Sublime Text 3 loses me, because it is proprietary. I agree with some of the concerns raised in this thread, but realize some see closed source with one benevolent dictator for life as a benefit [3]. Other editors I'm keeping and eye on are Adobe Brackets and Facebook's Nuclide. LightTable is interesting. I have given vim and emacs a spin, but I am not a keyboard jockey. Aint we got fun!
[1] https://discuss.atom.io/t/visual-studio-code-and-atom/16479/... [2] https://en.wikipedia.org/wiki/Electron_(software_framework) [3] https://forum.sublimetext.com/t/sublimes-future-and-open-sou...
LightTable was a clever idea that never quite fit my workflow, and which as far as I can tell is basically dead. The creators have abandoned it, and the surviving maintainer support is of the "pull requests welcome" variety. There are glaring bugs in basic features like inline eval, and maintainer response was a combination of "eh, we're cutting that feature anyway" and "fix it yourself."
Sure as hell doesn't give me any hope that this "Eve" thing their hyping is anything but smoke and mirrors.
However, Brackets new instant search is awesome and no other editor has it. For large projects I find it a great feature to be able to search all files in realtime as you type.
Looks like Emacs helm uses Silver Searcher which is real time, but impressively fast.
Do you use "in production"? Is it OK?
By the way, Find seems to be only working on three or more characters? How do I find two-letter substring? :)
edit: Regexp find is a bit slow overall (one 5-line file). Like it is waiting for a while before commiting to updating the UI. And that's on an i7 desktop, can't imagine it working on my Celeron laptop (but will give it a try later).
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.
If the file doesn't have any crazy long lines, i've had it handle 5mb+ files with no issues.
Wow! It's so exciting living in the 1990s!
I've had it handle 5GB+ files with no issues.
I've got a 6.3gb log file open in it right now.
It did take about 2 seconds to load the file though, so you can make fun of that!
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.
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.
Maybe a single thing bothers me: the search and replace UI wasn't very good the last time I checked, especially when trying to replace inside a selection.
What do you use Emacs for? Atom?
I still miss a few features from my previous editor (notepad++ on wine), such as the comments-only spell-checker and macros. But overall I'm happy with the transition.
Linter's work quite nicely (at least the Haskell, Bash, and Python ones). And git integration is useful. As usual with these highly modular text-editors, batteries are not included, and getting a good environment going can take up quite a while.
Performance has improved a lot. I don't care much about startup times, because I only start it once a week and then keep it running, but the rendering speed, too, has gotten much better.
The only thing I'm really still missing is column select.
Myself, I prefer Emacs, because I like it's base philosophy (everything is a text-buffer, everything is hackable LISP) and the endless possibilities that provides in form of customization, extensions (and extension on extensions, and customization of those, etc etc).
I don't think Atom is quite there, or ever will be. It will be interesting to see if if has the staying power of Emacs, or if it will yet another TextMate, Sublime Text or whatever hip text-editor of the month there has been the last decade.
I mean, you have to code your themes, therefore you have to know much stuff about the editor. In many IDEs you can just load a them and get a config UI that lets you fine-tune it.
He may be thinking about that?
Are you talking about themes in Emacs? Because if so, that statement is definitely not correct.
You can code your themes (and sometimes I do!), but it's definitely not the standard or only way of doing it.
If you're talking about Atom... Thanks for the info :)
Emacs has extensive preference setting functionality. There's lots of fine-grained configuration you can do, including themes, colors and fonts, without writing a line of elisp.
That said, elisp is fun to learn, no harder than JavaScript, and you can get pretty far customizing Emacs knowing just the basics.
To me, editors are on their way "out" if they can't keep up with the new languages / etc. Sublime text isn't going anywhere quickly. It can do a lot of things. If it can't keep up with other text editors it will still be usable, but may not be best option for everything.
People value notepad/nano for quick editing.
What role will sublime text play once a "superior" text editor comes into play?
It was inevitable that once a good cross-platform open source editor is available many people would jump ship.
ST is a great editor, but Atom has already surpassed it in most categories, thanks to the community. You can't beat that with a small team working on a closed source editor.
I too use Emacs, and another reply mentions that you have to learn Emacs (Elisp, etc) to program your thremes which is just plain incorrect. (See: https://github.com/mkaito/base16-emacs)
I'm a newish user of Emacs (around two years) having switched from sublime text. I can safely say I don't know much about elisp at all, but hope to some day.
I am never stuck in my ways, and always seek out tools that get the job done. Atom is actually quite impressive. Most of my co-workers use it on a daily basis (for JavaScript development).
... Man editing text in HN mobile blows in this tiny ass text box.
What keeps me in Emacs is it's philosophy as you said. There is a nice uniformity that the editor provides, and I can do practically anything. Atom has nearly stolen me from Emacs, but there are some issues in the past with some commands that have kept me from switching.
Let's see if this new version puts Emacs in my past.
While I am a diehard emacs user, I considered using atom for light editing (short enough that I'd want proper highlighting/indent support, but not long enough to get emacs out), but the lack of uniform buffer treatment was a dealbreaker for me. If you can't switch between settings and terminal screens using the same mechanism you switch between text screens with, and it all of the above don't have the same underlying mechanism, than you're doing it wrong.
I'd also recommend looking at the atom api docs, if you really want to switch.
I'd recommend sticking with emacs though. CLJS is a better lisp than elisp, but emacs is a better platform than atom.
I liked the design of Atom, but for this reason, I guess it's not the time for me to give up Emacs yet
Code and sublime just seem more solid. I don't need explosions in my editor when I'm focused.
Now I find that I open half my sessions in Atom, half in sublime.
I personally use Atom for lighter development and enjoy how easily accessible plugins are. Very easy to install support for lint tools/editorconfig/snippets/&tc.
Absolutely, yes.
I found it a little "bouncy" on first pass. It felt like there was an edge-of-perceptible lag when updating the display in response to keypresses. I tried switching to it again recently, and that's completely gone now. I guess it's just a tad on the slow side starting up, but everything else is really great, and I'm definitely sticking with it this time.
>Untitled documents in a project are now serialized and restored.
What are the primary reasons that drive people to Atom (or Visual Studio Code for that matter)? Is there some great feature that I'm missing out on?
Bit of a shame, I wouldn't have known about this update if I hadn't seen it here. While I appreciate auto-updating isn't for everyone, an in-app notification would have been useful.
But glad things are moving forward. Still haven't decided between Atom and Sublime though..
I personally still use Notepad++ as my "editor". Quick things like a git commit, just looking over a single log file or something, etc... Basically when i don't plan to be using it for more than a few minutes.
Atom comes out when i do development. It's more-or-less my IDE at this point. And when viewed through that lense, it starts faster than jetbrains does!
It was slow, it messed with tern-js a bit, and the brackets would "pop" into the viewport whenever i scrolled.
That was about a month ago so it may be better now.
Have you had any lock? It's annoying as hell as there is no close button either.
It seems like I'm a minority in that I don't want Atom to open the whole folder in the tree view when I open a file. What annoys me even more is that I want hot exit completely disabled, so that when I open Atom, no previous files/tabs or folders are open. I could never get this to work. The previously opened folder will always be present in the tree view when I open Atom again and when I open a file it will always open the folder in the tree view.
Does someone know if there is a workaround to this?
The barely noticeable lack of snappiness during editing is more than compensated for by the quality of the editor and its plugin ecosystem. I've also started using a ligature font for programming, which sublime doesn't support.
All I wanted was a non-blinking block cursor ...
Now I just found this https://github.com/olmokramer/atom-block-cursor
But more than 200 commits to support non-blinking block cursors? I think Atom is not for me.
It's not a good metric. Instead look at the 278 lines of code necessary to achieve it.
Btw, I develop on an 14'' i3 3rd gen, 8gig, no-ssd laptop, and I am able to do react-native dev, with the emulator running just fine
I setup the dev team of a startup(in Delhi, India) I was consulting with with Atom for react and node dev few months back. These guys were provided pretty shitty, and pretty old, 4 gig ram laptops. And they used to screw up things which could've easily been resolved with in-text-editor linting. I got them running atom with emmet, babel and ESlint, and they are still using it without any issues.
I have seen atom run reasonably well on really shitty machines. Its very hard for me to accept that all this complaining about its performance is not FUD.
I've been trying Atom every 3 months since it came out. Just a few plugins and Linting and is still very slow and I hate lag while typing.
I don't have this problem with Sublime, for example, where typing is instant. Even eclipse and Android studio are more responsive when typing.
It runs well enough on my laptop with a 4th gen i7, 8gb ram, ssd, running linux but cpu utilization is rather high. Scrolling inside a moderately sized file puts a 20-30% load on all 4 of my threads. If I enable on the fly linting, autocomplete features, minimap, and etc, it starts to add up.
I've used vim, emacs, and sublime text and I've found that with my uses cases (mainly python development), atom ranks at the bottom of efficiency and performance (but highest in productivity). I consider myself a proponent of atom and it's currently my favorite editor, especially with vim-mode but it has it's drawbacks. It's just not a fair fight; comparing the performance/efficiency of atom to editors written in c/c++ doesn't make sense to me.
Does anyone find JSCAD modeling inside Atom useful?
Tips/suggestions? I've been working on this project [1]
Why would a spacemacs user switch to atom? Does it have any advantages?
Spacemacs is an improvement, however I think it the biggest advantage it (and any other modern text editor) has over Emacs is the on-boarding process and general beginner friendliness.
Beyond that, Atom's modes for front-end web development are pretty top notch. We have js2-mode, and web-mode in Emacs, but the overall experience in Atom is often superior. For example, it's extremely easy to quickly install a color-picker, pull open a CSS file, and use a color wheel to make a hex value slightly darker. More, the color-picker UI feels tightly integrated into the editor.
On the surface, this feels trite, however the slow build-up of user friendly developer conveniences adds up.
The general command over the entire environment continues to draw me back to Emacs. Still, I continue to watch for when Atom can achieve this.