Re: ContentProvider/Resolver slow

[blake]

Brandt,

  It looks to me as if the only reason you need to release a cursor is to release the memory it holds.  I don't think it has much to do with the underlying SQLite cursor.  A cursor object holds the CursorWindow which allocates shared memory.  Have a look at: frameworks/base/libs/androidfw/CursorWindow.cpp

-blake

On Friday, March 1, 2013 2:23:38 PM UTC-8, Brandt Horrocks wrote:

Hopefully I can get a response from someone on the android dev team to answer the questions I have.

I work on a project for the Army that will be used by our soldiers.  Our problem is that the content provider interface that Android provides is too slow.  We have run hundreds of tests to gather data, and by direct comparison with SQLite calls (inside and outside a content provider), have concluded that content provider is too slow for our project.  When building our content provider and timing the direct database actions, the database actions are very quick; however, getting that data back to the entity that needs it is slow.  We are thinking that we will have to implement our own system to notify data observers.  In many ways, we would still like to use something like Content Provider that is more conventional.

Are there any plans for google to write a better content provider/resolver?

As an unrelated side note, we also have noticed that Android doesn't provide SQLite's full functionality (such as Write Ahead Logging intoduced in sqlite 3.7, I think) which would also speed up our data access.  Our system constantly hammers the database with small reads and writes, so this (for concurrency reasons) would be beneficial.  Using JNI, we utilized the sqlite C library in worst case scenario tests and WAL mode was much faster for us (we do not have large data insertions).  When the database is constantly being read in journal mode (the default), writes cannot occur as often as they should because read calls are blocking access.

Also, why does Android required one to close a cursor?  The way that sqlite is built, a close call isn't necessary when using it natively, (garbage collection will clean up the cursor).  We often have to track down open cursors because they are bringing the system down in a matter of speaking.  It is not like these are open-query-close in one method type interactions either, so it is easier for us to accidentally leave a cursor open.

Thanks!

[Ottavio Caruso]

On 1 March 2013 22:23, Brandt Horrocks <macad...@gmail.com> wrote:

>
> I work on a project for the Army that will be used by our soldiers.

Is it Al-Qaeda?

--
Ottavio

[Jean-Baptiste Queru]

This kind of message is not welcome here and is a sure way to get banned.

JBQ

> --
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
> To post to this group, send email to android-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/android-platform?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

--
Jean-Baptiste M. "JBQ" Queru
Technical Lead, Android Open Source Project, Google.

Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning.

[Brandt Horrocks]

Thanks for the response blake.  Yes, the memory needs to be released.  The way I understand it, the cursor when using sqlite directly will be cleaned up and collected, where as if we don't explicitly call close on an android SQLite cursor (via android calls), it will stick around.  I could be wrong, but that's what we have seen.

Perhaps I will have to dig around in the native code that you linked me to to figure out the differences.