Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Atom's Performance

blog.atom.io

Post reply on HN
Print view View original

131–140 of 293 posts

Re: The State of Atom's Performance

#131

Post by davidcelis »

nkkollaw wrote: post #126
HumanDrivenDev wrote: post #99

Earlier quoted context omitted.

VSCode is really bizzare, in a good way. All the configuration is done through JSON files. It's a good editor as well as an IDE. There's no "projects" or "solutions" or wizards. I almost never run into issues with it. It doesn't feel like a microsoft product at all. Nothing like Visual Studio.

I don't know about this. Configuration via JSON is common (Sublime Text, the most popular), I'd say that it's Atom that is bizzare on this aspect. As for "projects", I'd argue that if you open a folder, that's your project/workspace/whatever. Just thought I'd add this in case someone who doesn't know VS Code[ well] gets confused.

Atom can also configured via JSON files. They create their config file as CoffeeScript Object Notation (CSON) by default, but nothing is stopping you from changing it to ~/.atom/config.json

Re: The State of Atom's Performance

#132

Post by dchuk »

bronson wrote: post #101
oblio wrote: post #72

Earlier quoted context omitted.

My guess is that they can't challenge those assumptions since they'd break backwards compatibility for plugins.

When Atom makes serious changes to APIs, they find all published packages using those APIs and notify the authors that things are changing. Often the notification arrives as a pull request implementing the needed changes, along with an apology and an explanation of why the changes are necessary. It's impressive. I'm guessing the OP is hinting about moving off Electron?

Correct. Don't get a better whip for your buggy, get a car sort of thing.

Re: The State of Atom's Performance

#133

Post by joehewitt »

BugsJustFindMe wrote: post #88
joehewitt wrote: post #75

Earlier quoted context omitted.

> I don't use my computer exclusively for editing text, and therefore my text editor is not open all the time. Ok, well if I was developing a programmer's text editor I'd consider you a marginal user and design for the use case of the editor staying open 24/7. Startup time seems pretty low on the priority list.

Design for whatever you want to design for. Plenty of us are programmers who program all day every day and still don't agree with you. What you choose to prioritize is different from what you understand, though. So at least now you should "get" the gripes.

Well if the Atom developers are reading this I want to encourage them not to waste energy optimizing startup time due to Hacker News complainers who are using the product for a use case better suited to Notepad.

Re: The State of Atom's Performance

#134

Post by flukus »

stupidcar wrote: post #69
smacktoward wrote: post #51

Earlier quoted context omitted.

I would phrase the problem slightly differently: not "I want to use the technologies that make me enjoy my job," but "I want to use the technologies that I already know. " Electron is popular because it lets you write desktop apps in JavaScript, and there are a lot of developers out there who know JavaScript. By going with Electron, those developers can build desktop apps without having to learn anything new. They ca…

The thing is, are those alternative toolkits better ? Done right, they're faster, for sure. But when you use Electron you're leveraging thousands of man-years of Google developer effort to build a web browser that works consistently and well across different platforms. Although the web platform gets a bad rep for cross-browser compatibility problems and general weirdness, a huge amount of that goes away when you targ…

> The thing is, are those alternative toolkits better?

IME, yes. Most of those toolkits also have thousands of hours invested to work well across platforms, not consistently but natively, or at least a close facsimile of native.

> In that situation, you suddenly realise just how much power the web platform give you. You can style any element, any way you want. You have you have a complete, out-of-the-box object model for your whole UI, plus developer tools to help you debug it. You have advanced typography control. You can drop a canvas element in and get an immediate-mode 2D or 3D graphics API. You can layout stuff in flexbox or grid, or just as a plain old document (which most toolkits would delegate to an embedded web browser anyway).

So nothing that hasn't been true of desktop apps for decades then? If you want power then nothing beats being able to overide the paint method of a widget, you have complete and total control.

If you're interested in seeing how easy desktop apps are I built the canonical todo list in Gtk (https://gitlab.com/flukus/gtk-todo/blob/master/main.c), the goal is a demo that's a bit more complex than hello world. This is in a language not known for it's terseness, uses one of the nastiest parts of the framework (GtkTreeView) yet it still comes in at less than 100 lines of fairly straight forward and simple code.

Re: The State of Atom's Performance

#135

Post by tylerhou »

taternuts wrote: post #129
kalcode wrote: post #118

Earlier quoted context omitted.

That doesn't make sense...the browser always does the rendering of the dom. Not react. React speed when keeping your states and data in sync is that React makes all changes to the virtual dom then it makes it to the browser dom. It not different then the concept of batching graphic changes in a 2d game. You blit batches of sprites that need to be changed around the same frame instead of making 500 draw calls you make…

If a bottleneck is dom manipulation, then something that smartly batches them and reduces the number of times it's called would help. How would that not apply to Atom?

The article says this:

> In May, we rewrote Atom’s text rendering system from scratch, with the goal of making DOM updates after keystrokes as efficient as possible. We made use of the latest DOM technologies and rendering techniques, and built a tiny React-like library called etch that allows us to structure our rendering code cleanly while still allowing for imperative DOM manipulation for maximal performance in certain code paths. The result is that when typing, typical DOM updates now take less than 5 milliseconds: well within the range required for smooth animation and low energy usage.

Emphasis is mine.

Re: The State of Atom's Performance

#136

Post by hajile »

RobertRoberts wrote: post #113
shmageggy wrote: post #70

Earlier quoted context omitted.

> What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness. They specifically address those issues in the post: > Text Rendering Rewrite - Atom renders text... we rewrote Atom’s text rendering system from scratch, with the goal of making DOM updates after keystrokes as efficient as possible... The result is that when typing, typical DO…

Maybe they should rewrite it in React. I've been argued into the ground under the guise that it's faster than the browser's rendering of DOM.

They've been there and done that

http://blog.atom.io/2014/07/02/moving-atom-to-react.html

http://blog.atom.io/2014/07/22/default-to-react-editor.html

Turns out that for the important things in an editor, React has a hard time optimizing as much. I'm a huge proponent of React, but the right tool for the right job is an important principle for the pragmatic.

https://github.com/atom/atom/pull/5624

I think since then, they've circled around to a much more restrictive and faster virtual dom. React could be made quite a bit faster (as proven by Inferno) without changing the API and moving to a more monomorphic, but verbose API could probably offer a big performance boost.

I've wondered in the past if the best solution wouldn't actually be to render the editor part as a canvas element and remove the normal DOM from the picture completely. VS Code did something similar with their console a few versions ago.

https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...

EDIT: Looks like they've given some thought to canvas already (for the next go around). With webassembly, they could even offload to a nice C++ or rust library running and repainting a canvas element in another thread.

http://blog.atom.io/2017/06/22/a-new-approach-to-text-render...

Re: The State of Atom's Performance

#137

Post by valarauca1 »

dragonwriter wrote: post #104
valarauca1 wrote: post #59

Earlier quoted context omitted.

Emacs is very slow to start. Especially once you have a few extensions and addons. Emacs does an “unexec” operation to save its entire memory map to disk so its startup looks faster. But many people still run Emacs in a daemon. This preserves your sessions between “running the editor” and prevents ever having to restart.

> Emacs does an “unexec” operation to save its entire memory map to disk so its startup looks faster. The changes Atom is looking at regarding user-side snapshots seems conceptually similar.

This really scares me because the emacs unexec operation has had a ton of safety related bugs.

Re: The State of Atom's Performance

#138

Post by flukus »

oblio wrote: post #107
tebruno99 wrote: post #90

1.6G to .6G memory reduction is great. It’s a shame that most editors use 4-50mb

> Note also that these numbers are for users running Nuclide, which adds substantial functionality to Atom and increases its memory usage. Typical Atom users should see lower memory consumption.

It was a really odd graph to show actually, there's no context and it makes me suspicious. How are we supposed to know if all the memory improvements have come from atom or nuclide?

Re: The State of Atom's Performance

#139

Post by earenndil »

blueline wrote: post #116
stupidcar wrote: post #57

Earlier quoted context omitted.

Does it? I've not heard this myself, and the GitHub page says there's no native code in the main repo: https://github.com/Microsoft/vscode

whoops, maybe I've heard wrong then.

Apparently they use a lot of windows apis and dlls -- except that it works on linux and there's no c/++ to generate a dll, and I forget where I read that. (Somewhere on HN.)

Re: The State of Atom's Performance

#140

Post by acdha »

Zarel wrote: post #81
acdha wrote: post #61

Earlier quoted context omitted.

> Every time I type `git commit` This is true with something like Vi but with a separate GUI app, wouldn't the most common case be setting EDITOR={atom,code,etc.} and it simply opening a new window in the already-running app? (Or, for that matter, don't most people using something IDE-like use the built-in UI to make a commit?)

Opening a new window in the already-running app is also slow; they cover a strategy for increasing that performance in the linked blog post.

No doubt but e.g. VSCode’s sub-second performance shows that’s not a huge stretch while sticking with Electron and it has a subset of the challenges for startup performance
Post reply on HN