W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [IndexedDB] Callback order

From: Jeremy Orlow <jorlow@chromium.org>
Date: Thu, 24 Jun 2010 12:40:05 +0100
Message-ID: <AANLkTiniO2yVSkFu7-GhpN0pxCV8whZT9jJOpWF3cZC0@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Webapps WG <public-webapps@w3.org>
On Sat, Jun 19, 2010 at 9:12 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Fri, Jun 18, 2010 at 7:46 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > On Fri, Jun 18, 2010 at 7:24 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>
> >> On Fri, Jun 18, 2010 at 7:01 PM, Jeremy Orlow <jorlow@chromium.org>
> wrote:
> >> > I think determinism is most important for the reasons you cited.  I
> >> > think
> >> > advanced, performance concerned apps could deal with either semantics
> >> > you
> >> > mentioned, so the key would be to pick whatever is best for the normal
> >> > case.
> >> >  I'm leaning towards thinking firing in order is the best way to go
> >> > because
> >> > it's the most intuitive/easiest to understand, but I don't feel
> strongly
> >> > about anything other than being deterministic.
> >>
> >> I definitely agree that firing in request order is the simplest, both
> >> from an implementation and usage point of view. However my concern is
> >> that we'd lose most of the performance benefits that cursors provide
> >> if we use that solution.
> >>
> >> What do you mean with "apps could deal with either semantics"? You
> >> mean that they could deal with the cursor case by simply being slower,
> >> or do you mean that they could work around the performance hit
> >> somehow?
> >
> > Hm.  I was thinking they could save the value, call continue, then do
> work
> > on it, but that'd of course only defer the slowdown for one iteration.
>  So I
> > guess they'd have to store up a bunch of data and then make calls on it.
>
> Indeed which could be bad for memory footprint.
>
> > Of course, they'll run into all of these same issues with the sync API
> since
> > things are of course done in order.  So maybe trying to optimize this
> > specific case for just the async API is silly?
>
> I honestly haven't looked at the sync API. But yes, I assume that it
> will in general have to serialize all calls into the database and thus
> generally not be as performant. I don't think that is a good reason to
> make the async API slower too though.
>
> But it's entirely possible that I'm overly concerned about cursor
> performance in general though. I won't argue too strongly that we need
> to prioritize cursor callback events until I've seen some numbers. If
> we want to simply define that callbacks fire in request order for now
> then that is fine with me.
>

Yeah, I think we should get some hard numbers and think carefully about this
before we make things even more complicated/nuanced.

J
Received on Thursday, 24 June 2010 11:40:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:39 GMT