W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2013

Re: [whatwg] Script preloading: Browser Pre-compiled Scripts Cache?

From: Bruno Racineux <bruno@hexanet.net>
Date: Mon, 15 Jul 2013 16:28:51 -0700
To: Yoav Weiss <yoav@yoav.ws>, Boris Zbarsky <bzbarsky@MIT.EDU>
Message-ID: <CE09C122.6D1A1%bruno@hexanet.net>
Cc: WHATWG List <whatwg@whatwg.org>


On 7/15/13 3:02 PM, "Yoav Weiss" <yoav@yoav.ws> wrote:

>>
>> It goes beyond frameworks if based on pure 'access frequency'.
>>
>> For example, a site backend you use daily or you favorite web app would
>>be
>> also benefit.
>> Including the G+, Twitter and Facebook site's scripts, Map APIs, Google
>> News, or whatever you access most frequently from your machine.
>>
>
>For scripts that are always delivered through a single URL, no standard
>change is needed in order to make this optimization happen. As Boris
>pointed out, this is already done in Firefox [1]
Nods, I think I get what Boris said for the most part, reading the links
afterwards.


>
>> And I am not thinking 'installation' or 'packages' in the sense that you
>> expressed.
>> That was my early thinking too, but say Google providing jQuery and all
>> the hosted APIs preloaded in Chrome seems too difficult to handle, due
>>to
>> versioning aspects as well as limited scope.
>>
>> To be truly worth, it needs to be broad, based on access frequency by
>>urls.
>>
>
>Unfortunately, for framework caching, using only URLs for caching purposes
>have proven to be insufficient, resulting in very little code reuse across
>sites, because of multiple CDNS and versioning [2]

Well just to be clear, my suggested approach rely on URL 'access
frequency' beyond browser sessions, and beyond libraries.
i.e. The compiled cache only gets recycled for frequently accessed scripts.

If the most frequently accessed scripts turn out to be jquery 1.8.2 and
1.10.2 and 2.0.3, then all three are cached of even 10 versions is that's
the case.
Then possibly put to disk on browser shutdown and back to memory on start.
And say reserve a sticky cache of up to XMB of ram for those.
They oviously have to be re-cached as per given cache expiration.

But in that it doesn't really care about a particular library, it's
popularity or even it's code. It's code agnostics and mostly concerned
that the script you access every day are pre-compiled and never
re-downloaded until cache expiry. That's the idea.

>
>[1] https://bugzilla.mozilla.org/show_bug.cgi?id=883154

The outline there suggest: "- When compiling a lazy script with no inner
functions, do a table lookup for a script with the same source location
(filename, lineno, column, source begin/end"

I am no going that far with the overhead. My suggestion is to be only
interested in the unique URL hash (not line no, column, or source
begin/end). Just how many times that script has been accessed in the last
day, week or month.

Perhaps I am wrongly thinking of whole scripts vs thinking of "script" as
a "function body" like Boris suggested. I am not a browser-dev or c coder,
and only relying on php opcode as limited basis for my though process...

Or the "fundamental unit of compilation" for JS is incompatible with my
approach. IDK

>[2] http://statichtml.com/2011/google-ajax-libraries-caching.html
Received on Monday, 15 July 2013 23:29:10 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:03 UTC