On May 21, 2013, at 10:05 AM, Ben Kelly <[email protected]> wrote: > On May 20, 2013, at 3:18 PM, Joshua Bell <[email protected]> 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 >>> >>> >>> >> >> >
