Re: [IndexedDB] request feedback on IDBKeyRange.inList([]) enhancement

Thank you.

  - 1000 get() calls in single txn:             ~1600ms
  - getAll for all 1000 keys:                    ~1200ms

I would expect getAll could have better than that.

It seems context switching between js and database is cheap. In that case,
cursor walk could even better perform.

nsIDOMContact objects is fine, it is a typical object found in web app.


On Tue, May 21, 2013 at 10:05 PM, Ben Kelly <bkelly@mozilla.com> wrote:

> On May 20, 2013, at 3:18 PM, Joshua Bell <jsbell@google.com> wrote:
> > Cool. Knowing what performance difference you see between multi-get and
> just a bunch of gets in parallel (for time to delivery of the last value)
> will be interesting. A multi-get of any sort should avoid a bunch of
> messaging overhead and excursions into script to deliver individual values,
> so it will almost certainly be faster, but I wonder how significantly the
> duration from first-get to last-success will differ.
>
> Here are some rough wall-clock numbers for previous testing I've done.  In
> all cases we are loading 1000 nsIDOMContact objects in batches.  Time is
> essentially wall-clock to load the entire 1000 values in the data set.
>
>   - 20 get() calls per txn:                             ~2000ms
>   - 1000 get() calls in single txn:             ~1600ms
>   - getAll + inList for 20 keys per txn:                ~1500ms
>   - getAll + inList for 64 keys per txn:                ~1050ms
>   - getAll + inList for 256 keys per txn:       ~950ms
>   - getAll for all 1000 keys:                           ~1200ms
>
> I've hesitated to post these because they are somewhat specific to my
> workload, test case, and device.  I'll try to pull out a more isolated test
> case while I work on the optimization for parallel get() calls.
>
> > > > Ignoring deplicating keys is not a useful feature in query. In fact,
> I will like result be respective ordering of given key list.
> > >
> > > Well, I would prefer to respect ordering as well.  I just assumed that
> people would prefer not to impose that on all calls.  Perhaps the cases
> could be separated:
> > >
> > >   IDBKeyList.inList([])                 // unordered
> > >   IDBKeyList.inOrderedList([])  // ordered
> > >
> > > I would be happy to include duplicate keys as well.
> > >
> > > Thanks again.
> > >
> > > Ben
> > >
> > >
> > >
> >
> >
>
>

Received on Wednesday, 22 May 2013 02:01:33 UTC