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

Improving startup time in Atom with V8 snapshots

blog.atom.io

Post reply on HN
Print view View original

151–160 of 173 posts

Re: Improving startup time in Atom with V8 snapshots

#151

Post by rawland »

Unfortunately Atom is not on par with VSCode considering responsiveness.

There are a few more issues, Emanuel Quimper summarized in: https://equimper.github.io/2017/02/25/why-i-moved-away-from-... explaining why he moved from Atom to VSCode in detail.

A month ago there was an interesting submission in favor of Sublime Text 3. Mainly because of its incredible responsiveness: https://news.ycombinator.com/item?id=13928752 by Tristan Hume, comparing Vim, Spacemacs, Atom and Sublime Text. I highly recommend it.

My workflow now looks like this: VSCode+Plugins replaces my zsh+tmux+vim toolchain when running on AC. On battery zsh+tmux+vim provide VSCode+Plugins functionality with less beautiful gfx but unmatchable battery lifetime.

The zsh+tmux+vim toolchain is heavily customized, though: https://github.com/rscircus/dotfiles

Re: Improving startup time in Atom with V8 snapshots

#152

Post by posguy »

kasparsklavins wrote: post #149
Shorel wrote: post #125

Earlier quoted context omitted.

What is cheaper, more memory or a SublimeText license?

Depends on the region you're in. Around here an 8gb ram module costs the same as a sublime text license. I'll take the license.

I was just looking at a DDR3L 8GB module for $43, but I could perhaps see the value in Sublime at $70 a license if it significantly improves on Atom, but as it is I've yet to even fully utilize all that Atom offers, or have pain points.

Re: Improving startup time in Atom with V8 snapshots

#153

Post by posguy »

matt4077 wrote: post #145
WhitneyLand wrote: post #143

Is there any way not to conclude they have just been out designed/architected/optimized by Microsoft? What a compliment to the VSC team that after all this work, Atom still doesn't seem to match startup time, or more importantly perceived performance while editing. It's a more interesting comparison since they're both bound by similar constraints, and building cross platform apps. In the bad old days I once worked fo…

I'd offer the alternative theory that the VSCode team learnt everything they could from Atom's past mistakes. Speed is only one of the issues–I'm actually quite happy with Atom in that regard. VSCode has a much more restricted API, and a more robust extension system. With Atom, I always felt like extensions started interfering with each other, and with the 'vanilla' experience. OTOH, I was exploring a few ideas, such…

Sounds similar to the complaints about Firefox, though the only notable issues I've run into with Atom have been related to shared file editing (and resulting sync issues). If someone could just leverage etherpad lite with Atom, it'd make me so happy!

Re: Improving startup time in Atom with V8 snapshots

#154

Post by nsebban »

z3t4 wrote: post #121

Minifying the code can also speed up the startup time ... Another trick is to auto-start the app and bring it to the background (invisible). Then when the user "starts" it, just make it visible.

Your solution is a good one, but I get kind of sad when I remember the context : launching a text editor :/

Re: Improving startup time in Atom with V8 snapshots

#155

Post by vvggff »

posguy wrote: post #153
matt4077 wrote: post #145

Earlier quoted context omitted.

I'd offer the alternative theory that the VSCode team learnt everything they could from Atom's past mistakes. Speed is only one of the issues–I'm actually quite happy with Atom in that regard. VSCode has a much more restricted API, and a more robust extension system. With Atom, I always felt like extensions started interfering with each other, and with the 'vanilla' experience. OTOH, I was exploring a few ideas, such…

Sounds similar to the complaints about Firefox, though the only notable issues I've run into with Atom have been related to shared file editing (and resulting sync issues). If someone could just leverage etherpad lite with Atom, it'd make me so happy!

Would you pay?

Re: Improving startup time in Atom with V8 snapshots

#156

Post by senor_developer »

matt4077 wrote: post #145
WhitneyLand wrote: post #143

Is there any way not to conclude they have just been out designed/architected/optimized by Microsoft? What a compliment to the VSC team that after all this work, Atom still doesn't seem to match startup time, or more importantly perceived performance while editing. It's a more interesting comparison since they're both bound by similar constraints, and building cross platform apps. In the bad old days I once worked fo…

I'd offer the alternative theory that the VSCode team learnt everything they could from Atom's past mistakes. Speed is only one of the issues–I'm actually quite happy with Atom in that regard. VSCode has a much more restricted API, and a more robust extension system. With Atom, I always felt like extensions started interfering with each other, and with the 'vanilla' experience. OTOH, I was exploring a few ideas, such…

I'd offer the alternative-to-your-alternative-theory that the VSCode team had members that had lots of real world experience working on text editors and desktop apps, whereas Atom, based on the company's public statements on the matter, started as a hobby project by the CEO and slowly added a few very smart non-specialists over the years..

In other words, unlike the Atom team, VSCode didn't have to re-make mistakes Microsoft learned from 15 years ago...

Re: Improving startup time in Atom with V8 snapshots

#157

Post by drfuchs »

drfuchs wrote: post #138
winestock wrote: post #135

Earlier quoted context omitted.

And here's a relevant explanation from drfuchs. https://news.ycombinator.com/item?id=13076098 I quote it in full, here: OK, if you promise to stay off my lawn, I'll explain the history behind undump. Back in the 70's, the big CS departments typically had DEC 36-bit mainframes (PDP-10, PDP-20) running the Tops10/Tops20/Tenex/Waits/Sail family of operating systems. These are what Knuth used to do all of TeX, McCarthy L…

Hey! I don't get the karma points?!

12 hours later: Well, this has now garnered me more karma than my original posting; thanks, winestock!

Re: Improving startup time in Atom with V8 snapshots

#158

Post by frou_dh »

nilliams wrote: post #85
coldtea wrote: post #60

Earlier quoted context omitted.

> If this was truly that simple, don't you think someone would have already done it? Someone already has done it. An one-man-shop built Sublime Text by himself. Surely it's not having JS as an extension language as opposed to Python (the only difference between ST and what I propose) that's making it difficult. > Furthermore, is there even an actively maintained, open source, cross platform, development-focused text…

I think the developer behind Sublime Text is widely recognised as an outlier. >> "Sublime Text 2 is mostly coded in C++ and uses a custom UI toolkit." ... [0] How many other devs/teams are going to reasonably take that on. (And how do you think the debugging story of his custom framework compares to Chrome Devtools). [0] http://stackoverflow.com/a/9201645

> How many other devs/teams are going to reasonably take that on?

This strikes me as a sort of devolving-human standpoint that might lead to someone in 2050 asking how anybody could possibly walk 10 miles unassisted.

In the past, small teams of talented developers have written an entire game + game engine + associated tools from scratch, countless times.

Doing in-depth custom UI development for the desktop as part of creating a text editor does not bin as 'Mountain-moving; Don't even try' difficulty.

Re: Improving startup time in Atom with V8 snapshots

#159

Post by reissbaker »

Veratyr wrote: post #122
cwyers wrote: post #111

Earlier quoted context omitted.

No, it just resorts to the freaking JVM , which is not any more lightweight or native than Electron apps.

I don't think that's true. The JVM is far closer to native code than Javascript, both technically and in terms of actual performance. Here's some synthetic number crunching benchmarks: https://benchmarksgame.alioth.debian.org/u64q/javascript.htm... Even on the I/O heavy workloads that Node/V8 should be able to handle best, Java is ahead: https://www.techempower.com/benchmarks/ And yes, there are many Java apps that l…

The JVM is a virtual machine, just like V8, and neither is particularly "native." Java is an easier-to-optimize language than JavaScript, mainly because static types give better information to the compiler and prevent certain kinds of hard-to-optimize behavior from being written in the first place.

That being said, as someone who's used both Atom and IntelliJ a fair amount (although my daily driver is Vim), you can definitely see the downsides of using the JVM vs V8 in terms of startup cost. People complain about Atom being slow to start, but IntelliJ is so, so much worse — elsewhere in this thread dstaley mentioned it being almost 4x worse on a test file, and in large projects I've seen IntelliJ take literally minutes to begin being usable. The JVM is optimized for long-running server processes that can afford time to boot and warm up; the V8 team spends inordinate amounts of time ensuring that JS can begin executing quickly, even sometimes at the cost of peak performance. And RAM usage in IntelliJ isn't pretty either.

I don't think using the JVM instead of Electron buys much (if anything) in terms of editor performance compared to writing in native languages, like Rust or C++, and using native GUI toolkits instead of Swing/JavaFX or the DOM.

Re: Improving startup time in Atom with V8 snapshots

#160

Post by coldtea »

ruleabidinguser wrote: post #91
michaelmrose wrote: post #90

Earlier quoted context omitted.

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.

Well, it might not be ridiculous IF qualified.

E.g. "most of algol-derived languages are quite similar, aside from small differences in syntax and feature set".

Or:

"Most modern mainstream languages, etc have pretty much similar feature sets and syntax (while still differing in being dynamic vs statically typed etc)"

That's not the same as what you said.

Post reply on HN