Hi Ben - your comment is considered a Last Call comment and it was
included in the LC's comment tracking document [1].
In [2], Joshua proposed this comment be addressed/resolved as a feature
request and as such, it was added to the IDB feature request list [3].
For the purposes of tracking
On Jun 11, 2013, at 2:21 PM, Arthur Barstow art.bars...@nokia.com wrote:
Hi Ben - your comment is considered a Last Call comment and it was included
in the LC's comment tracking document [1].
In [2], Joshua proposed this comment be addressed/resolved as a feature
request and as such, it
On May 21, 2013, at 10:05 AM, Ben Kelly bke...@mozilla.com wrote:
On May 20, 2013, at 3:18 PM, Joshua Bell jsb...@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
On Jun 3, 2013, at 6:06 PM, Joshua Bell jsb...@google.com wrote:
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
On May 21, 2013, at 10:01 PM, Kyaw Tun kyaw...@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
On May 20, 2013, at 3:18 PM, Joshua Bell jsb...@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
I'm person
On Fri, May 17, 2013 at 2:37 PM, Ben Kelly bke...@mozilla.com wrote:
Hello all,
Recently I've been working on a mobile application that makes heavy use of
IndexedDB. In particular, there are times when this app must query a
potentially large, non-consecutive list of keys.
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.
Thanks for the feedback!
On May 19, 2013, at 9:25 PM, Kyaw Tun kyaw...@yathit.com wrote:
IDBKeyRange.inList looks practically useful, but it can be achieve continue
(continuePrimary) cursor iteration. Performance will be comparable except
multiple round trip between js and database.
I'm
On Mon, May 20, 2013 at 6:37 AM, Ben Kelly bke...@mozilla.com wrote:
Thanks for the feedback!
On May 19, 2013, at 9:25 PM, Kyaw Tun kyaw...@yathit.com wrote:
IDBKeyRange.inList looks practically useful, but it can be achieve
continue (continuePrimary) cursor iteration. Performance will be
On May 20, 2013, at 1:39 PM, Joshua Bell jsb...@google.com wrote:
On Mon, May 20, 2013 at 6:37 AM, Ben Kelly bke...@mozilla.com wrote:
On May 19, 2013, at 9:25 PM, Kyaw Tun kyaw...@yathit.com wrote:
IDBKeyRange.inList looks practically useful, but it can be achieve continue
On Mon, May 20, 2013 at 12:08 PM, Ben Kelly bke...@mozilla.com wrote:
On May 20, 2013, at 1:39 PM, Joshua Bell jsb...@google.com wrote:
On Mon, May 20, 2013 at 6:37 AM, Ben Kelly bke...@mozilla.com wrote:
On May 19, 2013, at 9:25 PM, Kyaw Tun kyaw...@yathit.com wrote:
IDBKeyRange.inList
Sorry, I always have problem with talking clearly.
Your experiment on this kind of problem is very interesting. I would like
to see what are optimal number of requests in a given transaction. These
two concepts (cursor walk and multi-request) can be employed together.
In my library
Hello all,
Recently I've been working on a mobile application that makes heavy use of
IndexedDB. In particular, there are times when this app must query a
potentially large, non-consecutive list of keys. Currently (to my knowledge)
the IndexedDB API requires that this be done via separate
IDBKeyRange.inList looks practically useful, but it can be achieve
continue (continuePrimary) cursor iteration. Performance will be
comparable except multiple round trip between js and database.
Querying by parallel multiple get in a single transaction should also
be fast as well.
Additionally
15 matches
Mail list logo
