- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sat, 19 Jun 2010 01:12:23 -0700
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Webapps WG <public-webapps@w3.org>
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. / Jonas
Received on Saturday, 19 June 2010 08:13:15 UTC