- From: Ben Kelly <bkelly@mozilla.com>
- Date: Tue, 21 May 2013 10:05:39 -0400
- To: Joshua Bell <jsbell@google.com>
- Cc: Kyaw Tun <kyawtun@yathit.com>, "public-webapps@w3.org" <public-webapps@w3.org>
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 Tuesday, 21 May 2013 14:06:10 UTC