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

On May 21, 2013, at 10:01 PM, Kyaw Tun <kyawtun@yathit.com> wrote:
> 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.  

I agree the getAll() result was not as expected.  I suspect there was something going wrong in my test, but I don't have a good explanation right now.  The improvements in time with subsequently larger inList() requests did suggest to me that round trips are significant on this device.

I really need to extract an isolated test.  Unfortunately it doesn't look like I will have time to do that until the first week of June.  I have some other work I need to do this week and I will be at JSConf next week.  Sorry for the delay.

> 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 12:32:33 UTC