*Code caching is another new technique that helps speed up page loading, specifically on repeated visits to the same page. Normally, the V8 engine compiles the page’s JavaScript on every visit, turning it into instructions that a processor understands. This compiled code is then discarded once a user navigates away from the page as compiled code is highly dependent on the state and context of the machine at compilation time. Chrome 42 introduces an advanced technique of storing a local copy of the compiled code, so that when the user returns to the page the downloading, parsing, and compiling steps can all be skipped. Across all page loads, this allows Chrome to avoid about 40% of compile time and saves precious battery on mobile devices.*
http://blog.chromium.org/2015/03/new-javascript-techniques-for-rapid.html Good news. On Friday, January 30, 2015 at 9:07:31 PM UTC+8, Yang Guo wrote: > > You are welcome to play around with code caching. Take a look at > CompileString in src/d8.cc or test/cctest/test-serialize.cc for examples. > > On Wednesday, January 28, 2015 at 6:01:22 AM UTC+1, Jiang Kelvin wrote: >> >> Thanks for sharing the details of technology. Maybe it is also really >> hard to return a kind of serializable compiled code and let the embedder to >> handle(e.g. store) it. >> I just thought about that if the "installation" process can do more. (For >> example if windows wanna run their applications on lots of devices based on >> X86/ARM/MIPS, I think a reasonable way is that do the back-end compiling >> works and linkings when installing.) >> >> On Tue, Jan 27, 2015 at 5:54 PM, Jakob Kummerow <[email protected]> >> wrote: >> >>> It's complicated. >>> >>> V8 has a so-called "snapshotting" mechanism which is used to speed up >>> startup. Recently people have been working on using it to cache other code >>> as well. >>> >>> That said, this is no silver bullet, as there are a number of inherent >>> challenges: >>> - dynamic languages like JavaScript are not well-suited for >>> ahead-of-time compilation >>> - generating optimized code depends on having collected type feedback, >>> so it can't happen up front; it also by definition bakes in a number of >>> non-cacheable assumptions >>> - generating non-optimized code, on the other hand, is relatively fast >>> anyway (unless there's a huge amount of it), so caching it only helps so >>> much >>> - assuming you have a working caching mechanism, you need reasonable >>> rules when to use it, how much disk space you're giving it, how you're >>> making sure it isn't stale, and so on. >>> - caching generated code doesn't affect sustained performance (possibly >>> on the contrary), it can only improve startup time. >>> >>> So having an explicit and time-consuming "installation"/pre-compilation >>> phase for JS packages isn't going to happen. However, more automatic >>> caching under the hood is something you're likely to see in the future >>> (regardless of where scripts came from -- there's no reason this couldn't >>> work with regular scripts found on web sites.) >>> >>> >>> On Tue, Jan 27, 2015 at 3:33 AM, Jiang Kelvin <[email protected]> wrote: >>> >>>> Not all js files are online, such as the js files in >>>> extensions/web-apps/application-cache. If we can save the result of >>>> compilation when installing or upgrading them, and just load and run the >>>> binary codes when calling a js function(think about the ART of Android), >>>> is >>>> it possible to improve performance? >>>> >>>> -- >>>> -- >>>> v8-users mailing list >>>> [email protected] >>>> http://groups.google.com/group/v8-users >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "v8-users" 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-users mailing list >>> [email protected] >>> http://groups.google.com/group/v8-users >>> --- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "v8-users" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/v8-users/2Gjwvzhjs0Q/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" 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.
