The State of Atom's Performance • Hacker News Board

Re: The State of Atom's Performance

#31

Post by robin_reala » Wed, Jan 10, 2018, 7:35 PM UTC

tonyedgecombe wrote: post #29

ParkerK wrote: post #3

>Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app. The majority of our code is written in JavaScript as opposed to C or C++, which is important for Atom’s extensibility, but makes it more challenging to ensure that the app starts quickly. Yet Microsoft's VSCode, which is also Electron based, is much faster than Atom. Electron obviously slows it d…

Also isn't the majority of Sublime Text written in Python which in my experience is slower than JavaScript.

No, common misconception. It just has Python bindings for extensions.

Re: The State of Atom's Performance

#32

Post by azeirah » Wed, Jan 10, 2018, 7:36 PM UTC

tonyedgecombe wrote: post #29

ParkerK wrote: post #3

>Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app. The majority of our code is written in JavaScript as opposed to C or C++, which is important for Atom’s extensibility, but makes it more challenging to ensure that the app starts quickly. Yet Microsoft's VSCode, which is also Electron based, is much faster than Atom. Electron obviously slows it d…

Also isn't the majority of Sublime Text written in Python which in my experience is slower than JavaScript.

The majority of Sublime Text is written in C++, it's extensible using Python.

Re: The State of Atom's Performance

#33

Post by Vekz » Wed, Jan 10, 2018, 7:36 PM UTC

ninjakeyboard wrote: post #16

I've been learning emacs over the last 6 month or so. How is the "hackability" of atom compared to emacs? I threw away spacemacs, started over, built all my config, am starting to build plugins etc. While the learning curve was steep, the flexibility of emacs is quite amazing and I've only just scratched the surface of the extensibility. It makes me very intrigued to hear about how other people are using editors like…

I would also like further discussion on this. I am full-time emacs. I hear from other colleagues that they will split time between editors. "vim for writing and VSCode for refactoring".

Re: The State of Atom's Performance

#34

Post by dchuk » Wed, Jan 10, 2018, 7:37 PM UTC

Reading updates like these from Atom reminds me a lot of some struggles I've seen with my teams in terms of how to breakdown problems you need to solve. I try to emphasize the idea of challenging the base assumption that current problems are stemming from to determine whether we've created our own issues or are truly facing problems we need to solve for our business.

People tend to ignore the base cause/assumption and hone in only on the problems that stem from those base causes/assumptions. Sometimes that's unavoidable, but often it's at the very least a good thought experiment to back up even further along the decision chain and challenge the original ideas instead. "Think outside the problems" or something I guess. It's really just making sure that you're being as methodical/objective as possible.

Atom seems to have been built with a set of initial goals/assumptions that triggered a massive chain reaction of problems to solve. Rather than challenging those original goals/assumptions, a lot of engineering talent and time is being invested in essentially cleaning up these problems that were self-imposed.

Re: The State of Atom's Performance

#35

Post by dawnerd » Wed, Jan 10, 2018, 7:37 PM UTC

joehewitt wrote: post #25

Don't get all the gripes about slow startup time. How often do you launch your editor? We're programmers - the editor stays open all the time!

I don't either. It's pretty fast as it is. Even if it took 10 seconds I don't think I'd mind too much as I close atom maybe once every few days, mostly by mistake (stupid cmd+q)

Re: The State of Atom's Performance

#36

Post by tony » Wed, Jan 10, 2018, 7:37 PM UTC

Here's a cool gem: https://github.com/atom/watcher

There are nice possibilities for this project, it could be abstracted out to work with FreeBSD and stuff. Grunt/gulp/etc. watch features may be able to utilize it in library form.

For a similar project, check out entr(1): http://entrproject.org/

I'm a full time VIM user, but I'm happy and glad anytime I see VSCode/Atom/etc win. I see it as a great editor for the sake of having one to recommend. Cross-platform, free, active plugin ecosystems.

Re: The State of Atom's Performance

#37

Post by rayiner » Wed, Jan 10, 2018, 7:37 PM UTC

tomjakubowski wrote: post #21

rayiner wrote: post #4

Earlier quoted context omitted.

Emacs' display engine, input handling, etc., are written in C.

And Electron’s are written in C++, so I’m unsure what your point is.

Yes and no. E.g. Atom does its line layout and rendering in Javascript, which manipulates the DOM, and Electron then renders things using C++ code: http://blog.atom.io/2017/06/22/a-new-approach-to-text-render....

Emacs' display loop is tens of thousands of lines of C that directly calls the native text-rendering API: https://www.facebook.com/notes/daniel-colascione/buttery-smo....

Re: The State of Atom's Performance

#38

Post by woolvalley » Wed, Jan 10, 2018, 7:37 PM UTC

joehewitt wrote: post #25

Don't get all the gripes about slow startup time. How often do you launch your editor? We're programmers - the editor stays open all the time!

There is also time to open new files as a subset of startup. Atom is significantly slower on large files than sublime.

Re: The State of Atom's Performance

#39

Post by swebs » Wed, Jan 10, 2018, 7:37 PM UTC

ParkerK wrote: post #3

>Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app. The majority of our code is written in JavaScript as opposed to C or C++, which is important for Atom’s extensibility, but makes it more challenging to ensure that the app starts quickly. Yet Microsoft's VSCode, which is also Electron based, is much faster than Atom. Electron obviously slows it d…

It is not "much faster" at all, both are horribly slow. (I can see how one would be convinced VSCode is fast if they're comparing it to Visual Studio which has absolutely abysmal performance). Though I could be convinced with newer benchmarks. All I could find was this experiment from a year ago that shows Atom and VS Code opening within a fraction of a second of each other, but Sublime and TextEdit beating both of them by an order of magnitude:

https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-...

Re: The State of Atom's Performance

#40

Post by camus2 » Wed, Jan 10, 2018, 7:39 PM UTC

arianvanp wrote: post #11

urda wrote: post #8

Earlier quoted context omitted.

Your point? Write slow javascript, get slow programs. It's not a crazy concept. Edit: typo

Emacs is written in Elisp which is a dynamic language just like JavaScript

> Emacs is written in Elisp which is a dynamic language just like JavaScript

All dynamic languages are not born equal when it comes to performance. 2 implementations of the same language aren't even equal. While V8 is a fast JS engine, the DOM isn't. Emacs doesn't rely on the DOM unlike Atom or VSCode.