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

101–110 of 293 posts

Re: The State of Atom's Performance

#101

Post by bronson »

oblio wrote: post #72
dchuk wrote: post #34

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 an…

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?

Re: The State of Atom's Performance

#102

Post by oiuyh87yy3 »

BugsJustFindMe wrote: post #43
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 would like to be the first to welcome you to the world where your personal preferences and experiences aren't universal. I don't use my computer exclusively for editing text, and therefore my text editor is not open all the time.

I mean, one can turn that around: If slow startup time is no good for you, don't use an editor with slow startup times?

Does a project need to consider each users edge-cases to be successful?

Also, I read the original post as slightly tongue in cheek.

Thanks for reminding us subjective experience is still a thing in this physical world.

Re: The State of Atom's Performance

#103

Post by michaelsbradley »

hsitz wrote: post #41
ninjakeyboard wrote: post #17

Earlier quoted context omitted.

emacs can be very slow to start if you install everything and the kitchen sink. I had spacemacs installed with everything for working with elixir and it took maybe 5 or 6 seconds to start. I started over from a blank init.el and I have it much quicker but it doesn't really matter because you just run a daemon and connect to it.

> it doesn't really matter because you just run a daemon and connect to it. I'm writing this because I think many people are unaware of this feature of Emacs and might gloss over it in your post. As far as I'm concerned startup time is next to irrelevant in Emacs, since you can start an Emacs server once when you boot up and then just run clients that open and connect instantaneously. That is, you can then run 'emacs…

On macOS, I have the following defined in ~/.bashrc:

   alias emacs="/Applications/Emacs.app/Contents/MacOS/Emacs -nw"
   alias e="et"
   alias eb="/Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q --eval \"(load-theme 'misterioso)\""
   alias et="emacsclient -t -a ''"
Explanation of the `-a ''` option per `emacsclient --help`:

   -a EDITOR, --alternate-editor=EDITOR
       Editor to fallback to if the server is not running
       If EDITOR is the empty string, start Emacs in daemon
       mode and try connecting again

Re: The State of Atom's Performance

#104

Post by dragonwriter »

valarauca1 wrote: post #59
gaius wrote: post #2

Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app And yet Emacs is fast, hmmm.

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.

Re: The State of Atom's Performance

#105

Post by bronson »

stratigos wrote: post #60

I want to believe! I want to like Atom so badly. I really buy into the features it offers over my beloved Sublime Text (3). I want the connectivity to the greater community, the ease of styling, and the ease of extension. I want everything Atom claims to offer! In my last year of switching from Sublime Text 2/3, I have pretty much just gained one thing: cooler language syntax styles. I havent actually taken advantage…

> First I lost lots of productivity configuring Atom to be in a similar state to how I use Sublime Text 3.

> Ive probably lost a cumulative total of 4-5 billable hours to Sublime Text in my whole life

It sounds like you haven't spent any time customizing Sublime? If so, then why did you need to spend so much time customizing Atom? They have a very similar out-of-the-box user experience (except for speed of course).

I'm interested to hear what needed changing.

Re: The State of Atom's Performance

#106

Post by [deleted] »

joehewitt wrote: post #77
loup-vaillant wrote: post #47

Earlier quoted context omitted.

Every time I type `git commit`. Every time I visualise files with ranger (terminal based file browser). Every time I typed an email, back when I was using Mutt —which I might again. For such quick jobs, launching the editor should be instantaneous . And I don't want to use another editor for them, I like the key bindings of my main editor.

Have you considered that Atom is not an editor meant for "quick jobs"? It's a workhorse for programmers who are coding all day every day.

[deleted]

Re: The State of Atom's Performance

#107

Post by oblio »

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.

Re: The State of Atom's Performance

#108

Post by [deleted] »

hsitz wrote: post #41
ninjakeyboard wrote: post #17

Earlier quoted context omitted.

emacs can be very slow to start if you install everything and the kitchen sink. I had spacemacs installed with everything for working with elixir and it took maybe 5 or 6 seconds to start. I started over from a blank init.el and I have it much quicker but it doesn't really matter because you just run a daemon and connect to it.

> it doesn't really matter because you just run a daemon and connect to it. I'm writing this because I think many people are unaware of this feature of Emacs and might gloss over it in your post. As far as I'm concerned startup time is next to irrelevant in Emacs, since you can start an Emacs server once when you boot up and then just run clients that open and connect instantaneously. That is, you can then run 'emacs…

[deleted]

Re: The State of Atom's Performance

#109

Post by ninjakeyboard »

Vekz wrote: post #33
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".

Ya I do periodically spend time in intellij when I work with scala, just because of the discovery and refactoring capabilities. Particularly very large/involved refactoring is helped by the tools. I did a core redesign to support an entirely new use case in a product I'm working on now. I tried to do it by hand and burnt a day, threw away everything, opened intellij, and applied a couple refactoring. In 40 minutes I had the tests passing for what was a very broad and wide refactor.

Re: The State of Atom's Performance

#110

Post by BugsJustFindMe »

Dirlewanger wrote: post #49
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!

VS Code's update cycle is like once per month which requires a restart. It starts up so fast that it doesn't even matter. Can't say the same for Atom.

If you're on the insider channel, the update cycle is daily. Microsoft's Code group is really knocking it out of the park with attention and responsiveness.
Post reply on HN