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] > <javascript:>> 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] >> <javascript:>> 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] <javascript:> >>> 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] <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> -- >> v8-users mailing list >> [email protected] <javascript:> >> 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] <javascript:>. >> 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.
