I have had similar issues. The problem is compounded when working
through a ContentProvider. I get only one or two database updates per
second *max* (involving a lookup for old value, delete of old row, and
rewrite of old row; update in place would only reduce this by a factor
of 2/3 by combining delete/insert into an update, and would cause the
system not to work with ContentObservers without taking an additional
large speed hit, see bug here:
http://code.google.com/p/android/issues/detail?id=665
).
In fact I am talking to a web service that provides data to my app.
It returns about 2 results per second, which is really slow for the
application domain I'm working in. And yet Android can't keep up with
even data supplied at that rate. I added a queue and an extra thread
so the web service doesn't have to block on the ContentProvider, but
now the queue just fills up quickly...
Additionally ContentProviders don't have a "batch update" or
"transactional update" mode, so you can't send a batch of updates to
SQLite all at once, which would speed the whole process up for my
application (although wouldn't speed up the original poster's
application).
I think it's a bigger problem that the entire database system in
Android was based on (1) SQL; (2) the relational model; and (3) flat
tables. Doing *anything* non-trivial (complex data dependencies etc.
-- anything that won't fit in a single table) takes a lot of work.
On Apr 15, 9:45 pm, hackbod <[EMAIL PROTECTED]> wrote:
> Once again: what you are running in the emulator is a complete ARM-
> based system (linux kernel, standard libraries including SQLite, and
> dalvik interpreter) being interpreted by the emulator.
>
> 8 seconds vs. .63 second = 12:1 performance difference is quite good
> for a complete ARM emulator. :)
>
> That said, running on a modern CPU, the emulator is going to give you
> something vaguely roughly similar to the performance on real device.
> Or in other words, the performance you see in the emulator is probably
> much closer to the real performance on a device than what you would
> get running that native x86 SQLite code. So you could well have a
> performance issue here, and need to tune your database (adding indexes
> and such) to improve performance.
>
> On Apr 15, 3:33 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> wrote:
>
> > I was shocked how slow SQLite works on Android.
>
> > For a selection of 374 rows, four columns (two integers and two
> > strings ~10 chars each), it took about 8 seconds.
> > Outside android same selection was finished in 63ms.
>
> > Of that time about 4 seconds each was taken by
> > SQLiteStatement.native_1x1_long and
> > SQLiteStatement.simpleQueryForLong.
>
> > Why is it so slow? Is it because of java interface, or sqlite itself
> > works that slow on Android? Will that be fixed soon?
>
> > Code was following
>
> > cursor = db.rawQuery("select attr_id, attr_name, attr_value, acc_id
> > from attributes", null);
> > while(cursor.next()){
> > ...
>
> > }
>
> > Db structure can be seen here
>
> >http://code.google.com/p/android-tabletop/wiki/DbPresentation
>
> > Thanks.
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
