12

to make it more specific, I mostly care about SpiderMonkey interpreter in Firefox.

So suppose I want to speed up the loading of a particular website in my browser or else speed up loading of all websites that have some popular script, e.g. JQuery. Presumably the scripts involved don't change between the page reloads. Will SeaMonkey understand that much and avoid full recompilation?

If SpiderMonkey wouldn't, will any other interpreter? Or is this basically a potential new feature which nobody cares about since computers are fast as is?

j0k
  • 22,600
  • 28
  • 79
  • 90
EndangeringSpecies
  • 1,564
  • 1
  • 17
  • 39
  • Not sure, you might want to check out http://ejohn.org/blog/tracemonkey/ and https://developer.mozilla.org/En/Nanojit . Hilarity: "Figuring out how to compile it is left as an exercise for the reader;" – Adam Bergmark May 11 '11 at 01:59
  • 1
    I think you mean SpiderMonkey, as SeaMonkey is a browser... – sdwilsh May 11 '11 at 14:20

1 Answers1

10

This is not an optimization Gecko does yet, but it's one we're looking into doing for sure. There are some complications to doing it, unfortunately.

Boris Zbarsky
  • 34,758
  • 5
  • 52
  • 55
  • thanks for your response. Question - is there a way to load / reload the page without reloading / recompiling associated javascript? E.g. website A and B use JQuery. So I load A and JQuery gets JIT-compiled. Why can't I now go to B and have the JQuery script simply stay in memory without being cleared for new recompilation? Is this an inherently complex issue? Or a minor modification that SpiderMonkey pro could do easily? For simplicity suppose we explicitly tell the app which scripts not to reload so there is no complex decision-making and if it doesn't work, we blame the user. – EndangeringSpecies May 11 '11 at 15:53
  • 2
    The current JIT compilation in the mode web scripts are run in bakes things like the pointer to the global object into the compiled code, for maximum performance. It also bakes in information about security decisions. That means that you can't reuse the same jit-compiled code against different global objects. You could disable the compile-and-go optimizations, but that still leaves the compartment issues and so forth. And deoptimizing all that to make reuse possible would lead to much slower code if done naively. – Boris Zbarsky May 11 '11 at 17:17
  • another question. Based on my experience with compilers for other languages, it would seem reasonable to imagine that whereas some scripts / functions would get DOM related pointers inserted into bytecode others would not. E.g. if there is a huge script called "yet another regex implementation" or some other such purely self-contained module, I would naively :) expect that nothing would be baked into its compilation. Am I being correct here with my assumption? Or is this DOM specific stuff baked into every 2nd line of the bytecode? – EndangeringSpecies May 11 '11 at 19:49
  • 1
    Any global variable access is accessing properties on the window, which is a DOM object. So any script which accesses any global properties (including Array, Math, String, any function or variable declared at global scope, etc, etc) is touching the DOM... – Boris Zbarsky May 12 '11 at 01:27
  • 2
    @Boris: Is this answer still correct as of today? Especially wrt [this SO question on the same topic](http://stackoverflow.com/questions/1096907/do-browsers-parse-javascript-on-every-page-load). – cha0site Feb 13 '12 at 20:11
  • @EirikHoem Yes, it is. – Boris Zbarsky Nov 06 '13 at 16:43
  • Is it actual for add-ins? I inject ~64 KB script on every tab via `tab.attach({contentScriptFile: ...` and fear that this has a negative impact on performance. – Artem Sep 04 '15 at 07:34
  • @Artem that probably makes things hairier yet; content scripts run in what [chrome docs](https://developer.chrome.com/docs/extensions/mv3/content_scripts/) call an "isolated world" (one world per frame/extension pair), which I think is just a kind of [realm](https://tc39.es/ecma262/multipage/executable-code-and-execution-contexts.html#realm) where the global object is some kind of mirrorverse version of the actual page's `window`: the document, elements, etc. are all there, but none of the stuff added by the page's scripts are there. Or maybe this actually makes caching *easier*. – SamB Sep 15 '22 at 21:49