On May 21, 2013, at 10:01 PM, Kyaw Tun <[email protected]> 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 <[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. > > > > > 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 > > > > > > > > > > > > > > >
