
Improved code caching - ingve
https://v8project.blogspot.com/2018/04/improved-code-caching.html
======
nbpname
This feature is really cool, however the ratio of parse-time and compile-time
improvement is not always meaningful to end users. I would be curious to see
the absolute & relative load-time gains.

When I was benchmarking Firefox on the same feature [1], back in November
2017, I noticed that reddit loads very little JavaScript that any improvement
on it does not matter.

Also, I wish that the benchmark website domains were not truncated, such as
"[http://www."](http://www."), and better distinguish websites such as
"[http://reddit."](http://reddit.") (for
[http://reddit.musicplayer.io](http://reddit.musicplayer.io)) as opposed to
"[http://www.reddit."](http://www.reddit.") (for
[http://www.reddit.com](http://www.reddit.com)).

[1] [https://blog.mozilla.org/javascript/2017/12/12/javascript-
st...](https://blog.mozilla.org/javascript/2017/12/12/javascript-startup-
bytecode-cache/)

~~~
Klathmon
They mention near the end of the article that it improved overall page loads
(time to interactive) on Android 1-2%

~~~
xboxnolifes
Fairly small, but all improvement is obviously welcome.

~~~
foepys
I'd argue that as long as it doesn't increase CPU load, those 1-2% are very
worth it on mobile. It's potentially 2% battery saved.

~~~
dymk
Only if your phone is spending all its time parsing javascript, and maybe 1%
(being generous) of its CPU time is spent doing that for a JS heavy page. So
1% of 1%. Really not much at all.

------
xfalcox
That's -60% parse time and -50% compilation time for Discourse[1].

I'm amazed by the changes the v8 team is pushing.

[1]
[https://github.com/discourse/discourse](https://github.com/discourse/discourse)

------
grapeli23
Everything is great. Only why from the introduction Ignition in Chrome 59
(2017-06-05) and resignation from V8 with Full-codegen, I have been recording
terrible regression on bellard.org/jslinux. Since then (Chrome 58), each newer
version is 3-4x slower.

~~~
lbenes
Have you reported these performance regressions on their bug tracker?[1] I
can't find it. Just time for the kernel to boot or you measuring something
else?

In my experience, they have been quite responsive to quality reports. Like
Mozilla, they have many tools to assist QA.[2]

[1]
[https://bugs.chromium.org/p/chromium/issues/list](https://bugs.chromium.org/p/chromium/issues/list)

[2] [https://www.chromium.org/developers/bisect-builds-
py](https://www.chromium.org/developers/bisect-builds-py)

~~~
grapeli23
Initially, it seemed to be a temporary regression. Later that it may be
related to Meltdown/Spectre mitigations. Currently, it is well-known to
developers and remains patiently waiting for improvement.
[https://bugs.chromium.org/p/chromium/issues/detail?id=827497...](https://bugs.chromium.org/p/chromium/issues/detail?id=827497#c4)

~~~
lbenes
From your report on the bug tracker:

> This is a non-regression issue as it is observed from M60 old builds.

No mention of the regression described here. If this is an issue you care
about, I suggest you check out the bisect-builds-py tool I linked to.

------
gildas
At SEO4Ajax, it looks like we're getting about a 5% performance gain when
scraping pages (we use Chrome 68 as I write this message).

------
kodablah
Can I use a timing attack to determine if my script has been seen before as a
fingerprint measurement? Meaning, is there a way via timing checks to
determine whether this is a cache hit which could tell me something about the
user? Or is it per domain and effectively like storing a bool in local
storage?

~~~
hashseed
You were already able to do this by loading any other kind of cached resource.

~~~
kodablah
While true, I was under the impression that there wasn't a cross-domain cache
that wasn't opt-in. Again, though, maybe this is per-domain so it's moot.

~~~
londons_explore
Simple cross domain <IMG> tags can have their load time measured..

------
sungju1203
but what is actually being cached?

~~~
Leszek
V8 engineer here: basically, a serialized walk through the object tree,
starting from the top-level script. Predominantly, this means bytecode,
scoping metadata, and strings.

~~~
nielsbot
Is x86/ARM binary code ever cached? Or is that not feasible? Seems like that
could save a lot of time?

~~~
thekingofh
I'd like to think so, though wouldn't dynamic typing insist branching would
still be possible so there's still likely some runtime checking before being
sure a precompiled bit is valid. All fascinating stuff.

~~~
nielsbot
I think you solve that by dynamic function specialization and perhaps also
trace compilation? [https://en.wikipedia.org/wiki/Tracing_just-in-
time_compilati...](https://en.wikipedia.org/wiki/Tracing_just-in-
time_compilation)

------
AstralStorm
Could someone add here a note in the title that it applies to JavaScript on V8
engine? I thought this was something related to caching actual executable code
in all languages.

