I know this almost a 6 year old post, but I am experiencing the exact issue
that you have measured in a production application, and am wondering if
anything more ever came of your research? I have a custom cursorAdapter
that is handling a cursor with ~10k rows in some instances. While scrolling
down is generally fine, there are points where scrolling back up, even one
row, causes a block in the UI thread for a few seconds. If a user is
attempting to quickly scroll up, the application can become unresponsive.
This is a huge problem for us, and I have currently been unable to find a
solution to this. You post here is really the only one I have come across
that seems to match the problem that we are seeing in large data sets.
Thank you.
On Wednesday, February 3, 2010 at 4:47:31 PM UTC-5, THill wrote:
>
> What you say makes sense Bob, but testing seems to indicate the
> Android SQLite implementation isn't so proper.
>
> I have a simple app that creates 20001 rows in a table, each with an
> int _id & 2 varchar fields.
>
> Getting the count of rows via db.rawQuery("select count(*) from
> table", null) and getting the value from the resulting cursor takes
> 0.2s.
>
> Getting the count of rows using
> cursor=db.rawQuery("select _id, field1, field2 from table",
> null); //NOTE: no 'where' or 'order by'
> count=cursor.getCount()
> takes 4.5s.
>
> During this time, the log has messages:
> E/CursorWindow( 695): need to grow: mSize = 1048576, size = 29,
> freeSpace() = 19, numRows = 11832
> E/CursorWindow( 695): not growing since there are already 11832
> row(s), max size 1048576
> E/Cursor ( 695): Failed allocating 29 bytes for text/blob at
> 11831,1
> D/Cursor ( 695): finish_program_and_get_row_count row 8169
>
> So, getCount() is certainly not optimal, and appears to be allocating
> something based on result set size. The list view requests the count
> of items up front, so a slow getCount() can impact the UI if you just
> trust SimpleCursorAdapter on large, simple queries.
>
> When scrolling down the list, each bindView results in a
> cursor.moveToPosition() call. Doing this in a test app shows that
> moving to 1000, 2000, ..., 20000 each takes 1ms -- except when going
> from 11000 to 12000, which takes >2s. No additional log messages.
>
> Where it gets u.g.l.y. is when moving from position 20000 backward to
> 0. 20000, ..., 12000 take 1ms, but moving from 12000 to 11000,
> 10000, ..., 0 *each* take 4.5s (!). This is really fun to observe
> when scrolling backward in the list from 12000. Once you hit some
> point, every row takes 4.5s before it is shown.
>
> When this starts happening, every move results in log messages like:
> D/dalvikvm( 320): GC freed 251 objects / 13256 bytes in 116ms
> E/CursorWindow( 763): need to grow: mSize = 1048576, size = 29,
> freeSpace() = 21, numRows = 11631
> E/CursorWindow( 763): not growing since there are already 11631
> row(s), max size 1048576
> E/Cursor ( 763): Failed allocating 29 bytes for text/blob at
> 19630,1
> D/Cursor ( 763): finish_program_and_get_row_count row 370
>
> This would again indicate the cursor is not agnostic to the result set
> size. I'll be doing more testing with many smaller query cursors
> behind a single adapter, but there appears to be a clear threshold.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/android-developers/6592705e-12dd-4e82-9ff1-f401203e25f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
