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 [email protected].
To post to this group, send email to [email protected].
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.
