Make simple-storage read its data asynchronously

RESOLVED WONTFIX

Status

Add-on SDK
General
P2
normal
RESOLVED WONTFIX
5 years ago
3 years ago

People

(Reporter: mossop, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
Irakli thinks we can load the data for simple-storage asynchronously by doing it during the time we are waiting for browser startup to complete.

Is it possible to do this faster than the browser startup takes (to delay our initialisation might break add-ons)?

How much slower would this make browser startup time with a pathological 5MB storage file?
(In reply to Dave Townsend (:Mossop) from comment #0)
> Irakli thinks we can load the data for simple-storage asynchronously by
> doing it during the time we are waiting for browser startup to complete.
> 

To be clear, we already read l10n data async and load hidden frame async and execute main add-on script only after all of these happen.

https://github.com/mozilla/addon-sdk/blob/master/lib/sdk/addon/runner.js#L99-L116

I think if we also read a simple storage data in parallel that would be an improvement over what we already got.

>
> Is it possible to do this faster than the browser startup takes (to delay
> our initialisation might break add-ons)?
>

Are you saying that if add-ons main script going to run later it will break add-ons ? I don't think it will, since addon's can be installed / enabled long after firefox is started so I don't really see why delaying startup of add-on little longer would break them.

> 
> How much slower would this make browser startup time with a pathological 5MB
> storage file?
>

I would this change only improve browser startup since reading will happen off the main thread in contrast to blocking browser which is what we do now. 

Maybe I'm missing or misunderstanding something though

Updated

5 years ago
Priority: -- → P2
(In reply to Irakli Gozilalishvili [:irakli] [:gozala] [@gozala] from comment #1)
> (In reply to Dave Townsend (:Mossop) from comment #0)
> > Irakli thinks we can load the data for simple-storage asynchronously by
> > doing it during the time we are waiting for browser startup to complete.
> > 
> 
> To be clear, we already read l10n data async and load hidden frame async and
> execute main add-on script only after all of these happen.
> 
> https://github.com/mozilla/addon-sdk/blob/master/lib/sdk/addon/runner.js#L99-
> L116

Hmm I wonder why localization could not be done async..

> I think if we also read a simple storage data in parallel that would be an
> improvement over what we already got.

There could be 5MB of data, that has to be parsed after it is read from disk, that could add a lot of time to add-on start ups which could be unnecessary.

> > Is it possible to do this faster than the browser startup takes (to delay
> > our initialisation might break add-ons)?
> >
> 
> Are you saying that if add-ons main script going to run later it will break
> add-ons ? I don't think it will, since addon's can be installed / enabled
> long after firefox is started so I don't really see why delaying startup of
> add-on little longer would break them.

This could harm UX imo, people will know they have add-on XYZ installed, and yet think "the damn add-on isn't working wth??" (time passes..) "oh now it is working now, damn Firefox is slow!"...

> > How much slower would this make browser startup time with a pathological 5MB
> > storage file?
> >
> 
> I would this change only improve browser startup since reading will happen
> off the main thread in contrast to blocking browser which is what we do now. 
>
> Maybe I'm missing or misunderstanding something though

The browser startup would be improved, but the add-on startup would be harmed.
Blocks: 840246
can we wontfix this?
Flags: needinfo?(rFobic)
We should just moving ppl from simple storage to gaia's async-storage:
https://github.com/mozilla-b2g/gaia/blob/master/shared/js/async_storage.js
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(rFobic)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.