Re: [chromium-dev] Some pointers regarding Compilation Script Cache
29 views
Skip to first unread message
Egor Pasko
Jun 27, 2022, 11:28:35 AM6/27/22
to mark....@gmail.com, Chromium-dev, v8-...@googlegroups.com
+v8-dev (take 2)
On Sat, Jun 4, 2022 at 12:37 AM Mark Meeus <mark....@gmail.com> wrote:
--Hi Everyone,I'm trying to figure out why chromium is not using script compilation cache when the script loaded from a page served by file:// (and not at all in an Android WebView)I am testing with this html:<html><head></head><body><script src="https://code.jquery.com/jquery-3.6.0.js"></script></body></html>When serving this page over file:// => performance profiler reports:Streamed: trueCompilation cache status: script not eligibleWhen serving over http://Streamed: false: script has code-cache availableCompilation cache status: script loaded from cacheCompilation cache: size127 kBHaving observed this behaviour with the Chromium profiling tool, I would like to trace it back in the Chromium source code.It's the first time I'm looking at Chromium code, and it's a bit overwhelming :-)I'm thinking the ScriptCacheConsumer would be involved, but a breakpoint in it's constructor doesn't seem to get hit when loading the page over http.The ScriptStreamer::ScriptDecoder DidReveiveData triggers on a breakpoint, even when the compilation cache is used.We have a pretty large javascript app which we also run on Android WebView, we could have a huge benefit from compiled script cache. On Android however, the script cache isn't always working on pages served over https either (script not eligible).So I'm actually searching for the code that decides wether a script is eligible or not for the code caching.Could anyone point me in the right direction?kind regards,Mark
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/9fe77bd9-f4da-4b1d-a9ea-f5d701d72b6en%40chromium.org.
Egor Pasko
seth.b...@microsoft.com
Jun 27, 2022, 11:57:20 AM6/27/22
to v8-dev
Hi Mark,
Thanks for getting in touch! I'm not familiar with Android WebView, so I'll let someone else comment on that topic. Regarding file: URLs, I believe that the problem is that file: URLs don't use the network cache. This seems sort of obvious, I guess: caching a file from a local disk on the same local disk would waste space and not speed anything up. However, when requests use the network cache, servers have the opportunity to respond with "304 Not Modified". When the browser receives that response, it can be confident in reusing code cache data from a previous load. See also the "Don't change code" section in "Code caching for JavaScript developers". Otherwise, the browser has no clear guarantee that the newly loaded file matches what it loaded previously, so it must re-parse.
file: URLs are not the only script loads that suffer from lack of code caching because they bypass the network cache. Last year, I worked on a feature to enable code caching for WebUI scripts. WebUI refers to web pages provided by the browser itself rather than a remote server, such as the History page or the Downloads popup. The feature is still disabled by default due to underwhelming results when we enabled it for a small percentage of users, but I hope to get time (eventually...) to return to it and improve performance. I suspect that the documents and code reviews related to that feature work might help point you in the right direction regarding scripts loaded by file: URLs or WebViews. Everything is linked from this bug: Extend V8 code caches to WebUI scripts.
Best,
Seth
Reply all
Reply to author
Forward
0 new messages