On Fri, Mar 4, 2011 at 1:38 PM, ben turner <[email protected]> wrote:
> Firefox does lazily deserialize cursor values, so the slowdown you're > noticing is most likely due to us preserving the order of request > callbacks by queuing every continue() call in line with the rest of > the transaction. Jonas had proposed a faster, high performance cursor > that did not respect this ordering, maybe that's all that you'd need. > > However, a few thoughts: > > 1. How do you know Page 5 even exists? We haven't exposed a count() > function yet... > 2. I think we should expose a count() function! > 3. Maybe we should expose a getAt(long index, <enum> direction); > function on indexes and objectStores? > A count function might make sense. But in this case, you could just jump forward to page 5 and see if you get an error or not. I'd lean towards just adding jumping forward to cursors for now though. If getting a single item at some position is popular, then we can always add it. Let's avoid adding prioritization of cursor.continue calls unless we have absolutely no other choice. J On Fri, Mar 4, 2011 at 12:11 PM, Olli Pettay <[email protected]> > wrote: > > On 03/02/2011 09:02 AM, Ben Dilts wrote: > >> > >> Why is there no mechanism for paging results, a la SQL's "limit"? If I > >> want entries in positions 140-159 from an index, I have to call > >> continue() on a cursor 139 times, which in turn unserializes 139 objects > >> from my store that I don't care about, which in FF4 is making a lookup > >> in IndexedDB sometimes take many seconds for even a few records. > > > > Sounds like there is something to optimize in the implementation. > > Have you filed a bug > https://bugzilla.mozilla.org/enter_bug.cgi?product=Core > > component DOM ? > > If not, please do so and attach a *minimal* testcase. > > > > > > Thanks, > > > > > > -Olli > > > > > > It > >> > >> makes no sense--am I just missing something in the spec? > >> > >> > >> Ben Dilts > > > > > >
