11 ms·
Atom 1.19 – Improved Responsiveness and Memory Usage
- kjksf 9y agoI'm tentatively excited about this release. It claims to fix the biggest complaint about atom: speed of editing and memory usage of edited files. They did it by re-writing backing store for documents from JavaScript to C++.
- noncoml 9y agoAnybody knows how come VSC is so more responsive than Atom? Is having parts in C++ a trick that VSC also does, or is it something else?
- hacker_9 9y agoVSC streamlines the data it needs to load, doing the least amount possible in hot paths as far as I know. They also multi-thread on startup so it is perceived as being quicker to boot up.
- pducks32 9y agoHonestly I use both often and just the startup makes it seem faster. Just the startup alone makes such a large difference to perception.
- murukesh_s 9y agoI think vscode was built with performance in mind from the ground up. Atom on the other hand was focussed on hackability. Down to actual reason, I haven't scanned the source code but have noticed vscode delegates lots of processing to separate child processes that could prevent potential freezing/lockups in the main process/window.
- ralfn 9y agoIt's not magic by VSCode, other web-based editing components such as the ACE editor are also lightning fast. There are two main reasons: - VSCode is rendering in the DOM what you see, not what you scroll to. - VSCode is using the correct datastructures, so an insert of a line at the top, doesn't require updating/relayouting all lines below it, but more likely something like log(n) lines. And these two reasons you can summarize as the difference between old skool engineers with proper training in datastructures, cache behavior and algorithmic complexity -vs- new skool "full-stack developers" that rely on a billion lines of code they haven't written (or understand) and who mainly script a bit in between. The (wrong) assumption in the recent decade was we don't need to train engineers to understand the algorithmic complexity of their code because 'computers will continue to become faster'. That was never true and never will be true, because an exponentially slow algorithm simply won't ever be fast enough regardless of the amount of transistors. And making something like a simple text editor (without syntax highlighting and all of that -- just being able to edit the code), is actually an easy test to distinguish between the two wildly different skillsets.
- systems 9y agoI dont see any C++ https://github.com/Microsoft/vscode https://github.com/Microsoft/vscode
- 0xcoffee 9y agoVSCode pulls in all sorts of precompiled dependencies during build. e.g. the search is done via RipGrep which is just a binary. But I agree that it is mostly typescript through and through, they just have implemented basically everything as a non-blocking promise. And most importantly, the extension system cannot block the UI. It runs in a completely different process also.
- ralfn 9y agoThe honest answer -- Microsoft has a lot of people with experience in building these things, so they aren't making the typical mistakes that Atom made with their architecture. For example: Atom was rendering dom nodes for your whole file -- not just the parts that were visible. Using the DOM as a stateful container of all that could be visible does not scale really well. Compare to something like the ACE editor (an OSS editing component that you can plug into any website) which is lightning fast -- it only renders what you see though -- but the filesize is not at all relevant to the performance. These are all techniques that people who ever wrote complex UI toolkits are incredible aware of. I don't think that describes anybody who worked on ATOM ever, which means they just have to relearn and re invent this stuff until they get it right. Generally, these days a lot of developers get a lot of experience combining existing technologies. Proper engineering skills, or even being aware of the data structures you are using and their algorithmic complexity, how cache friendly it is -- all of this is prioritized much less now. So Atom answers a simply question. Has hardware become significantly fast to not care about proper engineering? No, not really and it never will. If your datastructure is structured in a such a way that inserting a line all the way at the top requires a relayout of every line below that, for example, you will run into real limits.
- curiousess 9y agoAm I confused or is it not the case that the whole argument for Electron is "write once in Javascript, have a native app for all platforms"? If this is what a flagship Electron app has to do to be performant, is there a real future in Electron?
- kemayo 9y agoThat's part of it. The other part is "write using tools which lots of developers are familiar with", i.e. the general browser stack. That still applies. For that matter, even if your app requires occasional core high-performance bits written into C, that's probably still a benefit to you. Similar to the standard Python argument, which advocates a very similar development pattern. After all, it's not like you're not compiling it on each platform anyway to get the native app you're distributing.
- andyfleming 9y agoI think with any technology like this, as long as the structure of the wrapper (Electron, in this case) allows for cleanly integrating into lower level components of code, it's fine. The point is that the majority is managed in a lighter-weight accessible language. The majority of the application is still based on web technologies that a larger audience can contribute to. If they need to write something lower level for a core part of the application to achieve performance, I think that's alright.
- pelhage 9y ago> If they need to write something lower level for a core part of the application to achieve performance, I think that's alright. Which is the idea behind WebAssembly and why we're seeing it discussed more often these days
- usaphp 9y agoNot every Electro app should have to deal with a huge dom tree like Atom does. I just think the Electron is a bad fit for this particular type of application, but it does not mean it can be a bad fit for other type of stuff.
- nkkollaw 9y agoI've been waiting this for a while. They seemed to have a lot more beta releases than other versions. Perhaps because there were a lot more changes..?
- cordite 9y agoWill I not have to restart in safe mode if I open a 5MB JS payload? (It crashes the tabs and the editor, but I can still use the file menu and such)
- santaclaus 9y agoThere is nothing more horrifying in the known world than accidentally opening a 200meg log in VSCode or Atom... (both have other great advantages, though).
- Zelizz 9y agoMeanwhile I've opened a 20GB log in Sublime Text and done some actual work with it...
- SquareWheel 9y agoJust don't turn on syntax highlighting. I've made that mistake with a giant SQL file.
- ComputerGuru 9y agoA lot of vim plugins take a different approach that initially makes one think they are broken: they only render syntax based on what's in the buffer, which leads to things like HTML closing tags with opening tags not visible in the buffer (presuming you didn't scroll past the opening tag and jumped straight to the current position) won't be highlighted correctly, etc. but it means never having to parse the entire file just to get syntax highlighting working. It's a good compromise, on the whole.
- Froyoh 9y agoWow, looks like a full rework: https://github.com/atom/atom/pull/13880 https://github.com/atom/atom/pull/13880
- deleted 9y ago[deleted]
- hammerandtongs 9y agoThis seems like something that if they are going to address performance comprehensively they are going to need to benchmark and watch for improvements and regressions on their builds. https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/ Without some concrete benchmarks I'm not inclined to go to the trouble of trying it again.
- tracker1 9y agoWish they'd included VS Code in that comparison.
- chillee 9y agoI ran the tests myself a while back. http://imgur.com/0G3qbpr http://imgur.com/0G3qbpr One thing that really surprised me was that my terminal emulator made even things like nano or neovim have high latency. I suspect that most people don't really care that much about the difference between 30 and 10, but care whenever the latency spikes to 60-70 (which is more likely in VSCode and especially Atom, compared to neovim).
- mauro3 9y agoX-ref: https://github.com/Microsoft/vscode/issues/27378 https://github.com/Microsoft/vscode/issues/27378
- anotheryou 9y agobut with spell-check disabled to give it a fair chance :)
- butz 9y agoHow does VSCode manage to take up less disk space than Atom, with similar feature set? Currently on Windows box: VSCode 1.14.0 - 156MB Atom 1.19.0 - 516MB
- Bilters 9y agoThis might be an intersting article to read on the side; https://josephg.com/blog/electron-is-flash-for-the-desktop/ https://josephg.com/blog/electron-is-flash-for-the-desktop/
- striking 9y agoThey're both Electron-based. One is just less optimized than the other. (edit: the parent comment has been edited. Mine no longer makes sense in context.)
- deleted 9y ago[deleted]
- moosingin3space 9y agoWe really don't need yet another anti-Electron circlejerk here, especially when VS Code is also written with Electron.
- glibgil 9y agoThe developers of VS Code wanted it to take up less space? I'm sure someone could reduce Atom to the same footprint
- ComputerGuru 9y agoI don't think anyone is questioning that; I believe the OP's question was more along the lines of "what wasteful resource management strategies on behalf of Atom's developers lead to the product consuming so much space and running so slow?"
- whatsinaname22 9y agoSpeed is the reason I almost stop using Atom like a few times every year, this is awesome news.
- wobbelywobble 9y agoJust tested the new release, made sure it's indeed 1.19, and can definitely feel a big difference in performance. Nice job.
- krisives 9y agoThis means you can use sshfs again
- nkkollaw 9y agoI have to try that, I've been following the issue on GitHub for a while. It would be nice to not have to disable .git on mounted servers.
- debaserab2 9y agoNot to beat a dead horse, but: is there anything Atom does that VSCode doesn't already do better? Is there a reason to prefer it?
- ComputerGuru 9y agoI think Atom still exists because it got here first. I doubt it would have been created, let alone achieved the traction it has, had it not been "first to the market" in this particular niche.
- nobleach 9y agoOh I dunno.... back in the day, there was Texmate, and it was like a pretty Emacs. Then came Sublime, Coda and Espresso. That was an era of pretty text editors. I was used to vim, so all that beauty didn't really entice me. When Atom first was announced, I just figured it was another Sublime copy. I had no idea what Electron was at that time. I just thought... hmm, an editor from GitHub... ok... I'm sure there's some reason for it to exist. But from my perspective, it wasn't competing with other javascript/browser-in-a-box editors... it was just another in a long line.
- ComputerGuru 9y agoI meant JS-extensible and open source.
- computerex 9y agoVim can be incredibly pretty/beautiful... Aesthetics isn't exclusive to modern text editors! http://mohd-ali.com/images/aesthetic.png http://mohd-ali.com/images/aesthetic.png
- guessmyname 9y agoEach one has their own advantages and disadvantages. For example, VSCode is surely preferred more than Atom by Go developers because of the integration of the tools, Atom has the GitHub integration. And, maybe I am wrong, but I think that Atom has more people hacking it (making plugins and themes) than VSCode. At this point, VSCode vs. Atom is like VIM vs. Emacs.
- kin 9y agoThe improved responsiveness is absolutely noticeable for me. Great job and much appreciated!
- zerr 9y agoOK, so more and more C++/native stuff... Why not make a fully C++/native app? I don't see anything special in the UIs of Atom, VSCode, Bracket or whatever that is really hard to implement natively. It might be somewhat harder, but it is worth it.
- LeoNatan25 9y agoYes, but then an entire class of “developers” can’t “hack” on it because they have to learn C++, and that’s hard, apparently.
- robin_reala 9y agoYou’re talking about Sublime Text (among others).
- ythn 9y agoI thought Sublime Text was written in python
- guessmyname 9y agoI wonder why some people keep saying this. SublimeText is written in C++ with the Skia library [1] It exposes an ABI that you can consume via Python scripts. [1] https://news.ycombinator.com/item?id=2822114 https://news.ycombinator.com/item?id=2822114
- deleted 9y ago[deleted]
- krisdol 9y agoBecause designing UIs in a universally-understood, well-tooled markup language like HTML is a lot more developer-efficient than [insert-native-C++-library-here]. Electron allows the use of web tech on the front end with as many native or non-native calls on the backend as you want.
- 9y ago
- khanan 9y agoAnd yet, still it doesn't feel as responsive as PyCharm or IntelliJ -- despite the smaller footprint.
- ComputerGuru 9y agoSpeaking of responsiveness and memory usage... When Atom first came out, I was one of those people harping about how goddamn slow and unresponsive it was compared to ST2 (and later ST3). When I realized just how much those milliseconds meant to me, I decided to see what was faster than even ST out there and I ended up on neovim. It's 2017, and after two decades of fighting vi and vim at every corner, I am finally a convert. I spent (and still spend) a crazy amount of time getting neovim to behave the way I expect an IDE to behave, but the speed and responsiveness of vim in my terminal and the degree of customization finally, finally made me embrace (neo)vim and see the light, all these years later. (rust developer life tip: forget racer, it is absolute garbage and ridiculously immature and incomplete. It is eons away from being useful to "code via intellisense" and the list of missing functionality or just simply wrong functionality is longer than the list of things it gets right. Just as I was about to give up on rust code completions, I discovered rls and its mixed racer/rustc approach to completions and haven't looked back. The ide and language-independent nature of the language server protocol and its blossoming implementations for different cilents and different languages is incredible, I wish it all the best.)
- LeoNatan25 9y agoIf you are on a Mac, give BBEdit a try—it’s really fantastic.
- ericfrederich 9y agoTime to update this one? https://github.com/jhallen/joes-sandbox/tree/master/editor-perf https://github.com/jhallen/joes-sandbox/tree/master/editor-p... I want to like Atom becuause it's free and open source... but Sublime is so much faster.
- heja_bruh 9y agoThey got some time to re-implement javascript parts into another shitty memory-unsafe language, and it's trending on HN. What a time to live-in
- sbkg0002 9y agoWill it finally support gtk3 dialogs?
- ilovemesomeperl 9y agoThere was a thread on reddit about atom's insane memory usage recently