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

Cool, thanks for sharing!

>  cursor:       329ms
>  get:  88ms

^ Not surprising, given the async overhead

>  get:  88ms
>  getAll:       71ms
>  inList:       44ms

^ Looking at the test, it seems like getAll is fetching all 500 records in
the store whereas get and inList are fetching only 250? Am I misreading?


On Mon, Jun 3, 2013 at 2:49 PM, Ben Kelly <bkelly@mozilla.com> wrote:

> On May 21, 2013, at 10:05 AM, 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.
>
> I finally got some time to break out an isolated test case:
>
>   http://blog.wanderview.com/idb-inlist-test/
>
> Results for firefox nightly+inList() patch on my MBPr quad core:
>
>   cursor:       329ms
>   get:  88ms
>   getAll:       71ms
>   inList:       44ms
>
> Code for each test case can be found here:
>
>
> https://github.com/wanderview/idb-inlist-test/tree/gh-pages/scripts/tests
>
> I'm still new to the IDB API, so there is a good chance I made a mistake
> somewhere in the tests.  Pull requests or other feedback welcome.
>
> Thanks!
>
> Ben
>
> >
> >>>> 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
> >>>
> >>>
> >>>
> >>
> >>
> >
>
>