Re: [IndexedDB] Callback order

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