Energizing Atom with V8's custom startup snapshot(v8project.blogspot.com)
v8project.blogspot.com
Energizing Atom with V8's custom startup snapshot
https://v8project.blogspot.com/2017/05/energizing-atom-with-v8s-custom-start.html
17 comments
So this is basically the emacs startup hack? Ugh.
for those of us who aren't familiar - what's the emacs startup hack, and why is is detrimental?
The emacs startup hack is in it's use of a glibc function called "unexec", which essentially serializes the program's state into a single binary which can later be executed normally.
One of the big downsides (and the reason it became well known) is it's lack of portability, as it requires in-depth knowledge of the system's memory structures.
LWN article and previous HN discussion: https://news.ycombinator.com/item?id=11001796 Somewhat lower-level article that shines some light: http://emacshorrors.com/posts/unexecute.html
One of the big downsides (and the reason it became well known) is it's lack of portability, as it requires in-depth knowledge of the system's memory structures.
LWN article and previous HN discussion: https://news.ycombinator.com/item?id=11001796 Somewhat lower-level article that shines some light: http://emacshorrors.com/posts/unexecute.html
I was just going to remark, those that don't know history are doomed to repeat it.
What's wrong with the emacs startup hack that makes it something that's not worth repeating (and improving upon)?
To me it seems like a fantastic way to improve startup time regardless of language or ecosystem.
To me it seems like a fantastic way to improve startup time regardless of language or ecosystem.
Can we just compile js to bytecode? It's silly making huge apps in a language that has to be parsed and compiled on the fly
That would reduce largely the JavaScript runtime size, but not the rendering engine and all the vendored third-party libraries.
On my Arch Linux installation, the node.js package takes about 18.45 MiB on disk. While I'd be glad if the various multiple electron runtimes slimmed down by 10-15 MiB, it wouldn't be much.
On my Arch Linux installation, the node.js package takes about 18.45 MiB on disk. While I'd be glad if the various multiple electron runtimes slimmed down by 10-15 MiB, it wouldn't be much.
Get to work on a Webassembly compiler and your wish might be granted.
http://webassembly.org
http://webassembly.org
The Tanks demo makes my CPU hurt (15" rMBP, Firefox).
Why is WebGL still so heavy on the CPU?
Why is WebGL still so heavy on the CPU?
It works fine on my 2011 15" macbook pro with Firefox 54.0b4. I wonder if it is the high retina resolution thats the problem for you?
It might be because the macbook is also driving a 4k display at the same time.
It takes up about 2 percent of my 7 year old cpu in chrome. It is also compiled from Unity, so was not made from C++ directly.
Apple's OpenGl support is crap.
> Why is WebGL still so heavy on the CPU?
Well, how else are we supposed to get nice side channel / timing attacks?
Well, how else are we supposed to get nice side channel / timing attacks?
Sorry, but what an incredible kludge.
There are only so many brain cells on earth, can we stop using them to make javascript things on the desktop slightly less slow? Let's just not use it.
You think that's a waste of brain power? By 2014 humans had collectively spent 200,000 years playing angry birds. That was 3 years ago, and I'm sure pokemon go has at least tripled that record by now. Between than and all other video games we've probably spent in the tens of millions of years button mashing, if not the hundreds.
But yeah lets stop people trying to make JavaScript faster
But yeah lets stop people trying to make JavaScript faster