Why is asynchronous database access so much slower?

Question

Hi, I have an AIR app that loads and parses a data file
(approx 170 MB) and stores the parsed data in a database using the
built-in SQLite functionality. I have two implementations: one
synchronous, another asynchronous, both use transactions. The
synchronous one takes approx 5 minutes to complete. The
asynchronous takes approx 2.5 hours. The choice thus seems to be
between having an unresponsive program for 5 minutes, or having to
wait too long.
Did anyone else observer this significant difference? Is
there a 'known' reason for it? Is there anything that could
potentially be done to reduce the run time of the asynchronous
approach?

Answer 1

Thanks for posting your code; that helps a lot. I think
you'll find it instructive to watch CPU usage during the two demos.
Here's what's going on.
In the synchronous code, you are keeping the application busy
100% of the time because as soon as each insert is complete you
immediately schedule the next one. That's efficient although, as
you note, it makes the application unresponsive for too long a
period of time.
In the asynchronous code you are also waiting for each insert
to complete before scheduling the next one. The work done behind
the scenes for each insert is therefore greatly expanded:
1) An event is posted from the UI thread to a background
worker thread, scheduling the insert
2) The background thread wakes up
3) The insert executes on the background thread
4) The background thread posts an event containing the
results back to the UI thread
5) The UI thread eventually processes that event, delivering
it to your code
As you can see, there's a tremendous amount of overhead to
this. This is not really the way the async API is intended to be
used. Instead, try one of the following strategies:
A) Don't wait for each statement to complete before running
the next one. They'll queue up and run in order, but because the
background thread can process many at once, it runs much faster.
B) Chunk your synchronous inserts, e.g., run 100 inserts
every 100 msec or so. (You'll have to measure to find optimal
numbers.)
Hope this helps.