Re: ServiceWorker Cache API, the discussion is moving towards not adding explicit controls, but doing the right-ish thing implicitly. And there we probably already want to produce an eager code cache. (Details TBD, such as whether we will read the code cache in in pieces or all at once.)
(But that work is not going to happen any time soon.) On Wed, Apr 5, 2017 at 2:16 PM, Daniel Ehrenberg <[email protected]> wrote: > I've heard some early discussion of the possibility of explicit control > over caching code with ServiceWorker and the Cache API. As a follow-on to > the work described in Daniel's design doc (or its successor), what would > you think of adding that as an interface, to allow sites to opt into more > aggressive caching when they decide they can take the cost? For example, > the API could be having an option in an options bag for Cache.add, > Cache.addAll and Cache.put to perform the sort of background caching > described in Daniel's design doc, if the file is treated as JavaScript? > > Dan > > On Wed, Apr 5, 2017 at 1:55 PM, Yang Guo <[email protected]> wrote: > >> You can turn on --serialize-eager to make sure you compile as much as >> possible before creating the code cache. We currently haven't implemented a >> way to incrementally add to the code cache. >> >> Cheers, >> >> Yang >> >> On Wed, Apr 5, 2017 at 1:40 PM 'Daniel Vogelheim' via v8-dev < >> [email protected]> wrote: >> >>> I agree with your analysis, and I agree we could do better. Getting >>> there will take a bit, though. >>> >>> The reason why we currently cache only the immediately compiled >>> functions (which are top-level functions to IIFEs) is that the >>> serialization is fairly expensive. Just compiling more would help the >>> cache-hit case, but would have significant performance penalty for the >>> cache-miss case(s), and those are fairly common. I'd like to fix these >>> issues. Here >>> <https://docs.google.com/document/d/1-HhAgqRpHs9YQF9Zs7pTovUw8EE06tR3_zMIxaeCyOw/edit#heading=h.xgjl2srtytjt>'s >>> a suggestion on how, plus some background info. The feedback I've gotten is >>> that this is not the best way to proceed, so I'll need to do a bit more >>> work and adapt the design. I'll update the doc when I know more. As said... >>> it'll take a bit. >>> >>> Daniel >>> >>> >>> On Wed, Apr 5, 2017 at 1:15 PM, 阿炳 <[email protected]> wrote: >>> >>> Hi, V8's code cache in Chrome can significantly improve WebApp's startup >>> time, code caching is very important to modern WebApp as WebApp using more >>> and more js. >>> As I dig a little deeper in V8 code caching, I wonder whether we can do >>> more improvement on it. >>> Below is the trace result of http://m.sm.cn/s?q=%E9%A9%A >>> C%E4%BA%91&from=smor&safe=1&snum=6, before I capture this trace, I have >>> browse this url 4 times to make sure chrome generated code cache.(You can >>> find V8.CompileDeserialize in the table.) >>> >>> Though we have code cache, we still need 501ms in CompileCode, 1/3 of >>> total JS time. >>> What's the problem? >>> I think it's because we only cache the top level functions and IIFEs compile >>> result. >>> Is there any possible to store the code cache not just after the script >>> is compiled, but later like the page is loaded or time to interactive? >>> If we can store the code cache a little later, I think we can store much >>> more functions those are not in top level but will be called shortly after, >>> therefore we can significantly shorten the startup time of WebApp next time. >>> >>> >>> >>> Function Wall Wall self CPU CPU self wall average count >>> v8.callFunction 716.022 ms 616.025 ms 2.257 ms 1.809 ms 9.625 ms 64 >>> v8.compile 227.817 ms 151.827 ms 9.691 ms 7.658 ms 0.791 ms 192 >>> V8.Compile 49.760 ms 30.138 ms 35.384 ms 22.936 ms 0.158 ms 191 >>> V8.CompileCode 501.925 ms 378.723 ms 143.903 ms 117.921 ms 0.379 ms 1000 >>> V8.CompileDeserialize 1.436 ms 1.186 ms 1.436 ms 1.186 ms 0.237 ms 5 >>> V8.CompileIgnition 48.886 ms 35.360 ms 48.886 ms 35.360 ms 0.035 ms 1018 >>> V8.CompileScript 208.867 ms 137.379 ms 13.413 ms 9.672 ms 0.716 ms 192 >>> V8.DeoptimizeCode 0.038 ms 0.035 ms 0.038 ms 0.035 ms 0.035 ms 1 >>> V8.Execute 2,083.692 ms 1,662.409 ms 1,003.724 ms 764.488 ms 5.523 ms >>> 301 >>> V8.GC_Objects_Stats 0.000 ms 0.000 ms 0.000 ms 0.000 ms 0.000 ms 2 >>> V8.GCCompactor 74.109 ms 66.842 ms 0.179 ms 0.171 ms 33.421 ms 2 >>> V8.GCPhantomHandleProcessingCallback 0.244 ms 0.210 ms 0.105 ms 0.070 ms >>> 0.105 ms 2 >>> V8.GCScavenger 22.378 ms 19.512 ms 0.371 ms 0.219 ms 9.756 ms 2 >>> V8.ICStats 0.000 ms 0.000 ms 0.000 ms 0.000 ms 0.000 ms 1 >>> V8.NewContext 97.478 ms 87.695 ms 19.344 ms 17.471 ms 87.695 ms 1 >>> v8.newInstance 1.829 ms 1.521 ms 0.782 ms 0.567 ms 0.035 ms 43 >>> V8.OptimizeCode 6.630 ms 6.548 ms 0.118 ms 0.118 ms 6.548 ms 1 >>> V8.ParseFunction 144.272 ms 116.927 ms 144.272 ms 116.927 ms 0.159 ms >>> 735 >>> V8.ParseProgram 129.480 ms 85.579 ms 96.469 ms 58.753 ms 0.448 ms 191 >>> V8.PreParse 33.011 ms 26.826 ms 33.011 ms 26.826 ms 0.363 ms 74 >>> V8.RecompileSynchronous 6.512 ms 6.430 ms 6.512 ms 6.430 ms 6.430 ms 1 >>> v8.run 1,376.877 ms 1,053.397 ms 6.397 ms 5.232 ms 5.486 ms 192 >>> V8.RunMicrotasks 2.101 ms 1.444 ms 2.101 ms 1.444 ms 0.206 ms 7 >>> V8.ScriptCompiler 218.126 ms 144.169 ms 9.259 ms 6.790 ms 0.751 ms 192 >>> >>> -- >>> -- >>> v8-dev mailing list >>> [email protected] >>> http://groups.google.com/group/v8-dev >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "v8-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> -- >>> v8-dev mailing list >>> [email protected] >>> http://groups.google.com/group/v8-dev >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "v8-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> >> >> >> * • * >> *Yang Guo** • **Google Germany GmbH* >> * • *Erika-Mann-Str. 33 >> * • *80636 Munich >> >> • [email protected] >> >> >> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle >> >> Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: >> Hamburg >> >> Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, >> leiten Sie diese bitte nicht weiter, informieren Sie den Absender und >> löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is >> confidential. If you are not the right addressee please do not forward it, >> please inform the sender, and please erase this e-mail including any >> attachments. Thanks. >> >> -- >> -- >> v8-dev mailing list >> [email protected] >> http://groups.google.com/group/v8-dev >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
