Chrome : V8 Engine
Update - 19/03/2015
- Script Streaming
Starting 98 in version 41, Chrome parses async and deferred 97 scripts on a separate thread as soon as 96 the download has begun. This means that 95 parsing can complete just milliseconds after 94 the download has finished, and results in 93 pages loading as much as 10% faster.
- Code caching
Chrome 42 introduces 85 an advanced technique of storing a local 84 copy of the compiled code, so that when 83 the user returns to the page the downloading, parsing, and 82 compiling steps can all be skipped. Across 81 all page loads, this allows Chrome to avoid 80 about 40% of compile time and saves precious 79 battery on mobile devices.
Opera : Carakan Engine
In practice this 78 means that whenever a script program is 77 about to be compiled, whose source code 76 is identical to that of some other program that 75 was recently compiled, we reuse the previous 74 output from the compiler and skip the 73 compilation step entirely. This cache is 72 quite effective in typical browsing scenarios 71 where one loads page after page from the 70 same site, such as different news articles 69 from a news service, since each page often 68 loads the same, sometimes very large, script 67 library.
Firefox : SpiderMonkey Engine
SpiderMonkey 64 uses
Nanojit as its native back-end, a JIT compiler. The 63 process of compiling the machine code can 62 be seen here. In short, it appears to recompile scripts 61 as they are loaded. However, if we take a closer look at the 60 internals of
Nanojit we see that the higher level 59 monitor
jstracer, which is used to track compilation 58 can transition through three stages during 57 compilation, providing a benefit to
The 56 trace monitor's initial state is monitoring. This 55 means that spidermonkey is interpreting 54 bytecode. Every time spidermonkey interprets 53 a backward-jump bytecode, the monitor makes 52 note of the number of times the jump-target 51 program-counter (PC) value has been jumped-to. This 50 number is called the hit count for the PC. If 49 the hit count of a particular PC reaches 48 a threshold value, the target is considered 47 hot.
When the monitor decides a target PC 46 is hot, it looks in a hashtable of fragments 45 to see if there is a fragment holding native 44 code for that target PC. If it finds such 43 a fragment, it transitions to executing 42 mode. Otherwise it transitions to recording 41 mode.
This means that for
hot fragments of code 40 the native code is cached. Meaning that 39 will not need to be recompiled.
It is not 38 made clear is these hashed native sections 37 are retained between page refreshes. But 36 I would assume that they are. If anyone can find supporting evidence for this then excellent.
EDIT: It's been 35 pointed out that Mozilla developer Boris 34 Zbarsky has stated that Gecko does not cache 33 compiled scripts yet. Taken from this SO answer.
I think that 32 the best answer for this implementation 31 has already been given by someone else.
We don't currently cache the 30 bytecode (or the native code). It is an
option 29 we have considered, however, currently, code 28 generation is a
trivial portion of JS 27 execution time (< 2%), so we're not pursuing
this 26 at the moment.
This was written by Maciej Stachowiak, the 25 lead developer of Safari. So I think we 24 can take that to be true.
I was unable to 23 find any other information but you can read 22 more about the speed improvements of the 21 latest
SquirrelFish Extreme engine here, or browse the source code 20 here if you're feeling adventurous.
IE : Chakra Engine
This is quite 17 unofficial, but for IE's older engine implementations, Eric 16 Lippert (a MS developer of JScript) states in a blog reply here that:
JScript 15 Classic acts like a compiled language in 14 the sense that before any JScript Classic 13 program runs, we fully syntax check the 12 code, generate a full parse tree, and generate 11 a bytecode. We then run the bytecode through 10 a bytecode interpreter. In that sense, JScript 9 is every bit as "compiled" as 8 Java. The difference is that JScript does not allow you to persist or examine our proprietary bytecode. Also, the bytecode is much higher-level 7 than the JVM bytecode -- the JScript Classic 6 bytecode language is little more than a 5 linearization of the parse tree, whereas 4 the JVM bytecode is clearly intended to 3 operate on a low-level stack machine.
This 2 suggests that the bytecode does not persist 1 in any way, and thus bytecode is not cached.
Opera does it, as mentioned in the other 8 answer. (source)
Firefox (SpiderMonkey engine) does 7 not cache bytecode. (source)
WebKit (Safari, Konqueror) does 6 not cache bytecode. (source)
I'm not sure about IE[6/7/8] or 5 V8 (Chrome), I think IE might do some sort 4 of caching while V8 may not. IE is closed 3 source so I'm not sure, but in V8 it may 2 not make sense to cache "compiled" code 1 since they compile straight to machine code.
It's worth nothing that Google Dart explicitly tackles 4 this problem via "Snapshots" - the 3 goal is to speed up the initialization and 2 loading time by loading the preparsed version 1 of the code.
InfoQ has a good writeup @ http://www.infoq.com/articles/google-dart
I think that the correct answer would be 12 "not always." From what I understand, both 11 the browser and the server play a role in 10 determining what gets cached. If you really 9 need files to be reloaded every time, then 8 I think you should be able to configure 7 that from within Apache (for example). Of 6 course, I suppose that the user's browser 5 could be configured to ignore that setting, but 4 that's probably unlikely.
More Related questions