728197 - Investigate asynchronously populating the DOMStorage cache

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Marco Bonardo [:mak]]

Having DOMStorage use only async APIs would be really simple to achieve, though its APIs require synchronous access.
A possible idea to implement may be to use a ScriptBlocker to asynchronously copy the scope data in the cache on first access. Then access to the cache would stay synchronous.
Though, this may result in the page blocking on the first DOMStorage access, even if just for a brief moment.

Looking for thoughts/feedback.

Comment 1

[David Teller [:Yoric] - still alive but not very active]

Can a ScriptBlocker delay page load without freezing ui?

Comment 2

[Marco Bonardo [:mak]]

it won't free our UI, would free the content probably.

Comment 3

[Marco Bonardo [:mak]]

#developers pointed out that ScriptBlocker doesn't exactly block this way. Following the code it just seems to disallow adding new ScriptRunners, that are instead queued up and executed when the blockers count goes down to zero.  That means this bug is probably invalid.

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

We could maybe delay the "load" event for pages that already have DOMStorage data? Not sure if that is knowable though (we certainly wouldn't want to delay all page loads). Maybe sicking has an idea here?

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yeah, ScriptBlockers won't do anything for you here at all. It's a completely different thing.

I think the best thing we could do is to cache the whole thing on the first access. It would still be synchronous IO, but it would be a lot less than we currently do. And we can be smart about purging the cache on a timeout after the user leaves the page so that if you return to the same site (or browse between pages on the same site) we only do the loading once.

Comment 6

[Marco Bonardo [:mak]]

(In reply to Jonas Sicking (:sicking) from comment #5)
> I think the best thing we could do is to cache the whole thing on the first
> access. It would still be synchronous IO, but it would be a lot less than we
> currently do.

That's what I'm doing in bug 712009, but it's lot of complication cause I have to use 2 different connections, one for synchronous reads and one for asynchronous writes.  Having everything synchronous or asynchronous would largely simplify things, and since we want asynchronous writes...
Or, if we accept losing the durability part of the database we may use the asynchronous IO vfs. In case of crashes the next access may miss some data.

Btw, resolving invalid since we already have bug 712009 and bug 704933 with a bunch of discussions.

Comment 7

[Honza Bambas (:mayhemer)]

(In reply to Jonas Sicking (:sicking) from comment #5)
> Yeah, ScriptBlockers won't do anything for you here at all. It's a
> completely different thing.
> 
> I think the best thing we could do is to cache the whole thing on the first
> access. It would still be synchronous IO, but it would be a lot less than we
> currently do. And we can be smart about purging the cache on a timeout after
> the user leaves the page so that if you return to the same site (or browse
> between pages on the same site) we only do the loading once.

As I know the code, localStorage mem temp table, a.k.a the cache, is filled on the first use of localStorage, not the instantiation nor the window creation.  However, that is done on the main thread.

Also, we flush (and I think also delete?) the mem table every 5 seconds, and after mak implemented his idea for storing back just what has been modified, we are probably in much better position.

Comment 8

[Marco Bonardo [:mak]]

(In reply to Honza Bambas (:mayhemer) from comment #7)
> Also, we flush (and I think also delete?) the mem table every 5 seconds, and
> after mak implemented his idea for storing back just what has been modified,
> we are probably in much better position.

Vladan implemented it, I just had the idea (bug 714964 for reference). Sure, we are now doing much less writes, and I confirm there is already a memory cache for reads.

The current scope I'm chasing (in bug 712009) is to move those fsyncs to the async thread.