Live data from Hacker News

Improving startup time in Atom with V8 snapshots

blog.atom.io

91–100 of 173 posts

Re: Improving startup time in Atom with V8 snapshots

#91

Earlier quoted context omitted.

2 things 1. I don't think literally all programming languages are the same 2. I have used Haskell, and am very aware of every language listed in the other replies to this comment, so you're completely wrong. I kind of thought this community was better than this, to be honest.

This community is in fact pretty good you posted something wholly and totally ridiculous and the worst thing anyone has said is that you need to get out there and get more experience. Try saying silly things on reddit and watch the hate flow in.

Well sure we beat reddit I guess, and maybe I just don't post here enough, but I feel like the community is deteriorating. I used to hold this place to higher standards. Also I still don't think what I said was ridiculous, and its something I basically believe.

Re: Improving startup time in Atom with V8 snapshots

#92
post #44
post #25

Earlier quoted context omitted.

About 10 seconds of startup opening a directory, from terminal to loaded workspace. I'm on a MacBook Pro (Retina, 13-inch, Early 2015). I have 76 community plugins installed.

76? Daaam. I thought I was overdoing it at 53. (If anyone wants to check: ls ~/.atom/packages | wc -l # minus 1 for the README Have you checked Timecop? (cmd-shift-p, "timecop") Might be a few you can do without.

`apm list --installed --bare` is also a good one-liner.

Re: Improving startup time in Atom with V8 snapshots

#93

I started this issue a long time ago, and it's been frozen since: https://github.com/electron/electron/issues/3041 Maybe now we can have actual source code protection?

if you want to protect your source code, don't use Javascript.

>don't distribute your programs

That's what it really comes down to. From what I can see, it's mostly an emotional response. I'd be surprised if code/binary obfuscation is a net win in general.

I've had to disabuse developers of this idea. One distributed binaries that weren't quite valid but ran on the CLR, though not Mono. A 10 line script was enough to remove the invalid sequences. What did the developer gain in this case? An extra build step, undoubtedly more than one bug, and in the end, no "protection".

Re: Improving startup time in Atom with V8 snapshots

#94
post #34

Earlier quoted context omitted.

You can basically do that now: just don't quit. If you start Atom and it discovers that it's already running, it tells the running process to handle the request. It even honors environment variables and flags like --dev. For example, starting Atom cold on my medium-sized project (by running `atom .` in the base dir) takes 6 seconds. If I close all windows but leave Atom running, do something else for a while, and the…

This is really simple procedure that should take like a millisecond why does it take seconds?

I always hated this argument. It feels to me like someone is complaining why a train can't go from 0-60 in 10 seconds while many cars can. The answer is always "because that's not what it's designed to do".

Regardless of how you feel about it, the team behind Atom made a design decision to sacrifice performance to gain a large amount of other benefits ("easier" higher level language, easy cross platform support, extremely easy to write plugins for it from it's target "demographic", etc...).

Because of those architecture choices, things like spawning a new window aren't as easy and straightforward as they might be in another architecture.

So just because you want a method of transportation that goes from 0-60 in 10 seconds, doesn't mean that all methods of transportation need to go from 0-60 in 10 seconds. And just because a method of transportation can't go from 0-60 in 10 seconds doesn't mean the designers were lazy or cut corners, it just means that they prioritised other things, and are solving different problems.

Re: Improving startup time in Atom with V8 snapshots

#95

I'm way more worried about memory issues while running. Atom take up 1 gig+ with very little open. It pushes all my other tools out of RAM and into swap. Switching to the browser to see documentation takes a few seconds if I'm lucky. Compiling a few more seconds to page in. Ssh a few more. Everything on my laptop slows to a crawl as they fight for RAM with Atom taking up the way more than it should. I know the answer…

I don't get this. I've built text editors in JavaScript. I've built Electron apps. Granted, I've never built a text editor in Electron. But it's gotta be some trivial combination of my past experiences. I don't understand why Atom is such a pig.

Re: Improving startup time in Atom with V8 snapshots

#96

I'm way more worried about memory issues while running. Atom take up 1 gig+ with very little open. It pushes all my other tools out of RAM and into swap. Switching to the browser to see documentation takes a few seconds if I'm lucky. Compiling a few more seconds to page in. Ssh a few more. Everything on my laptop slows to a crawl as they fight for RAM with Atom taking up the way more than it should. I know the answer…

> For some reason, my machine seems to be getting slower and slower no matter how much I upgrade.

I've been feeling this way for years, and I've mostly ascribed it to my faulty perception. I figured that if things simply aren't getting faster (i.e., they're not changing at all), I'm probably just imagining them getting slower.

But then I start wondering why aren't things getting faster...

Re: Improving startup time in Atom with V8 snapshots

#97
post #22

Earlier quoted context omitted.

I hope you're right that this goes the way of emacs. I've been productive in emacs for 30 years, but I'm growing impatient for emacs to get a real programming language with lexical scoping like they were talking about doing with Scheme 20 years ago. Despite its lack of macros, JavaScript is arguably a better Lisp than Emacs Lisp. I've toyed with Atom a couple of times recently and am seriously thinking of switching.

See, I just don't understand why you would want to use emacs over an editor that does all the work for you. Thats why I avoid it, it seems like a big cost that I don't have to pay if I just use a different editor.

How do you think an IDE "does all the work" for you? Somebody working on the editor wrote some code in C++ or Java or whatever that makes it do that, and that code is baked into the IDE.

In emacs, the only missing part is that perhaps nobody has already written the elisp that makes it do whatever task you are asking for.

emacs is a smallish program written mostly in C that defers to a scripting language for nearly everything, and it ships a bunch of code in that scripting language that does all the work of being an editor. You can look at that code using the editor itself, and you can change that code using the editor itself. It's insanely flexible and extensible; see e.g. advice [0], and most modules provide meaningful hooks for you to add your own code.

All the IDE/editor behavior is just code. If it's compiled and baked into your IDE, fixed, unchanging, then if there is any behavior you don't like, you better hope the dev included a knob that lets you tweak it, or you have a lot higher barrier to making your editor work the way you want it to.

[0] https://www.gnu.org/software/emacs/manual/html_node/elisp/Ad...

Re: Improving startup time in Atom with V8 snapshots

#98

I started this issue a long time ago, and it's been frozen since: https://github.com/electron/electron/issues/3041 Maybe now we can have actual source code protection?

Why do you consider it valuable to give people an application and make it harder to debug when it crashes or misbehaves?

Because the end user shouldn't have any debug access, only the developer. Errors should be handled in application. In worst case (total exit of process from an error) Most people don't have error handling anyway. (And I don't want the only tool required to evade the license check to be notepad + asar)

Re: Improving startup time in Atom with V8 snapshots

#99

I started this issue a long time ago, and it's been frozen since: https://github.com/electron/electron/issues/3041 Maybe now we can have actual source code protection?

if you want to protect your source code, don't use Javascript.

I like javascript. It makes development faster. I'd like to prevent people from editing plain text (!!!) to evade my licensing check!

Re: Improving startup time in Atom with V8 snapshots

#100
post #84

Great article. Avid ST3 user here, but glad to hear about the improvements. For anyone curious, I made a quick gif comparing startup times on my machine for Sublime Text 3 (Build 3129), Atom (1.16.0), Atom Beta (1.17.0-beta2, the one mentioned here), VSCode (1.11.2), and VSCode Insiders (1.12) https://media.giphy.com/media/3ohzdTHkfj5ISAAPq8/source.gif I should mention - my ST3 is heavily customized (28 plugins), whi…

They all look to be within the same ballpark; none of those startup times would be a problem for me, at least. But when I tried Atom it was noticeably less responsive, which I have very little tolerance for. I haven't tried VS Code. (I also use Sublime)

My experience is that VSCode is much more responsive than Atom.

Just a lot "snappier". Startup is not much of a problem, I don't open ordinary files in VSCode or Atom by default (I use gedit for that)

Post reply on HN