Fetching js over the net is slow (multiple orders of magnitude slower than parsing).
Optimized compilation is slow (an order of magnitude).
But you can't even do baseline compilation without knowing what's in your evironment. For example, JSC (from WebKit) compiles to bytecode. But the compilation process happens lazily, as functions are first executed. (There is a quick pass to check syntax, beforehand. V8 does this too AFAIR.)
But OK, let's say you're parsing. You parse, create an AST, and go to compile it. The result of bytecompiling for V8 is native code! You can't cache that effectively, it will embed too many runtime constants. For JSC you do produce bytecode, but that bytecode too is dependent on runtime object layouts: for example if you reference a binding in the global object, and the binding is present, then the compiler will produced an indexed lookup into the global. That depends on what's in the global when the compilation unit (function, eval, or global code) is compiled. Caching is a security / correctness risk, in that context.
And then you have the negative impacts of caches on browser memory footprint (and associated GC cost).
It's no wonder why modern JS engines prefer to just keep around the source, and re-parse on demand.
You might be surprised. I ran some benchmarks[0] and found a significant parse time, and significant differences between browsers. tldr: a) parsing has a measurable cost, b) the parser is different from the interpreter, and the speed of one has little or no bearing on the other.
To be fair, parsing does take time. And if you're parsing 5MB+ of JS generated by something like Emscripten or GWT, it can take a sizable amount of time. It just tends to be small in comparison to the combination of network traffic and actual compilation.
"We don't currently cache the bytecode (or the native code). It is an option we have considered, however, currently, code generation is a trivial portion of JS execution time (< 2%), so we're not pursuing this at the moment."
Basically, it's not going to be a bigger saver compared to all the other parts of the process (e.g. fetching the file over the network).
what I don't understand, is why browsers don't just include the core stuff like that in the actual build.
There are like a dozen javascript frameworks that people use...so why not keep the latest copy of jquery and YUI for example on the user's harddrive? Surely there is space for say, 2-3mb of different javascript libraries.
Then all you have to do is simply ignore the jquery/yui inclusion code when you render the page, and just load it from the harddrive instead.
No sweat for you, but your users and developers might actually find that when they use your browser they get a slightly faster experience.
Someone in another thread (sorry, don't remember which) made a good point that including several frameworks by default would discourage people from trying new/novel/less popular frameworks.
I think linking to the library from Google's CDN is a nice compromise since it greatly increases the chance that it'll already be cached.
You can always link to the framework, so at worst your user will find the site a few seconds slower to load.
Then if there is adoption, you can always be included in the next build of the browser. All these frameworks tend to be tiny(i.e. jquery is huge, but is something like 30 kb), so nothing is stopping the browser from including all the possible frameworks on the harddrive.
Old browsers would ignore the extra 'signature' attribute, while new browsers could check for that library in their included, pre-optimized list and skip the download if its found.
Seems like it would solve a lot of problems at once without affecting backwards compatibility.
If you want to remove the need to redownload global assets/parse them on every page load, you can use pjax to do so. It'll only reload certain parts of the page that you specify, meaning if, for example, you're using Rails 3.X and all the code for the views require jquery and the jquery_ujs adapter, you'd stick that into your application.js manifest.
In your views you'd have a javascript_include_tag (or just the src tag) to that view's JS file. From there, between clicking on links within the same domain, it'll only reload the parts you tell it to.
Chrome also caches the compiled JavaScript in the HTTP disk cache. The biggest performance wins are for large scripts used by many web sites (such as jQuery).
V8: "This stores compiled JavaScript using a hash of the source for up to 5 garbage collections."
Hmmmm - is that across sessions? Does that mean I can detect if a user has visited other sites by timing how long it takes to eval a static script copied from those sites?
I've been wondering the same thing about CSS recently. With the advent of SCSS and other CSS preprocessors our CSS files are blowing out of late, and I am starting to worry about parsing time.
Does anyone have any good sources on
a) caching of CSS parse trees
b) what the latest thinking is on CSS file size, # of selectors, complexity of selectors for page load times.
Thinking of writing something about this myself but I am wondering what's out there.
Google found that moving from a 10-result page loading in
0.4 seconds to a 30-result page loading in 0.9 seconds
decreased traffic and ad revenues by 20%. Tests at Amazon
revealed similar results: every 100ms increase in load time
of Amazon.com decreased sales by 1%.
Fetching js over the net is slow (multiple orders of magnitude slower than parsing).
Optimized compilation is slow (an order of magnitude).
But you can't even do baseline compilation without knowing what's in your evironment. For example, JSC (from WebKit) compiles to bytecode. But the compilation process happens lazily, as functions are first executed. (There is a quick pass to check syntax, beforehand. V8 does this too AFAIR.)
But OK, let's say you're parsing. You parse, create an AST, and go to compile it. The result of bytecompiling for V8 is native code! You can't cache that effectively, it will embed too many runtime constants. For JSC you do produce bytecode, but that bytecode too is dependent on runtime object layouts: for example if you reference a binding in the global object, and the binding is present, then the compiler will produced an indexed lookup into the global. That depends on what's in the global when the compilation unit (function, eval, or global code) is compiled. Caching is a security / correctness risk, in that context.
And then you have the negative impacts of caches on browser memory footprint (and associated GC cost).
It's no wonder why modern JS engines prefer to just keep around the source, and re-parse on demand.