Hacker News Reader

Comment by saagarjha | Hacker News Reader

I see a GIF of someone going deleting a couple lines of code, with a meter showing that the application is maintaining 60 FPS. Was this not something Atom could do before? It seems to me that the bare minimum should be maintaining 60 FPS while performing basic editing tasks…is there some nuance here I'm missing?

View on HN

The GIF is just intended to represent an idea - that parsing (for the purpose of syntax highlighting and other code analysis) can no longer impact the app's frame rate, because it has been offloaded onto a background thread. The actual operations depicted in the recording are not a performance breakthrough.

Ok, that's nice to know. I know my initial comment probably came off as the stereotypical Hacker News sneer, but in my defense the picture, at least to me (having not used Atom for more than four years due to its poor performance when I tried it in the beta) makes it look like Atom was having issues maintaining a decent frame rate for the editing task shown, and is now able to provide this.

Or, to put it another way: your depiction in the article really makes it easy for those who have reservations about using Atom to come to the wrong conclusion, and it's not one that paints it in a good light. Might I suggest replacing it with a GIF that showcases the actual issue that this release was supposed to fix?

That really depends on what you measure by "frame rate".

In a single-threaded setup, maintaining 60fps is likely impossible. You may think of "just deleting a few lines of code" as trivial. But syntax highlighting alone requires re-parsing, as will automated formatting, type inference, and whatever else we expect today. It's unlikely for this to be done within the 16ms frame budget.

If you're offloading such work to separate threads, you can draw the frame right away and maintain 60fps. But you won't be able to update all the meta-information and frequently see "flashes of unstyled code".

Then you probably don't appreciate what tree-sitter has to offer.

https://galois.com/blog/2017/12/tree-sitter-new-parsing-syst...

> bare minimum should be maintaining 60 FPS

Yours would be a nice world to live in.

I've seen IntelliJ and Eclipse both crawl when doing "basic editing tasks". Hell, Vim does it too if your line length is long.

> Hell, Vim does it too if your line length is long.

Or even if it is short if you're using LaTeX with syntax highlighting. This even has its own entry in the manual, called tex-slow (http://vimdoc.sourceforge.net/htmldoc/syntax.html#tex-slow).

But IntelliJ and Eclipse (depending on the language) run compilers to do code checking right? Certainly too many text editors don't work very well with large text files which is a bit funny.

Yes, Intellij and Eclipse are IDEs, like Atom.

Not sure why you think an editor should refresh it's view port 60 times per second while idle.

It's not exactly about refreshing 60 times per second, but actually, not hanging the main thread for more than 16ms at a time. That means it _could_ do 60fps if the user performs actions fast enough, not that it will actually update 60 times per second while idle.

I'm 99% sure this is just terminology lifted from games. Just means it runs at a constant fast rate.

I have seen changesets for Atom before that include something like "make typing faster and more responsive".

Generally most of those changes are for when someone is using 25+ cursors at once, or are in very large documents that reflow a ton on every character.

Typing a single cursor in most documents was never really an issue in Atom. But when you layer on a ton of plugins that do all kinds of stuff, and add in some complicated grammars with larger documents and lots of cursors at once, then performance would start to suffer.

Reply on news.ycombinator.com