[TIMOB-3419] Android - SQLite insert is very slow
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Low |
| Status | Closed |
| Resolution | Won't Fix |
| Resolution Date | 2017-07-27T21:05:33.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | Android |
| Labels | android, defect, klist, reported-1.6.1, rplist, sqlite |
| Reporter | Pedro Enrique |
| Assignee | Ingo Muschenetz |
| Created | 2011-04-15T03:44:54.000+0000 |
| Updated | 2017-07-27T21:05:33.000+0000 |
Description
A http://developer.appcelerator.com/helpdesk/view/76471">helpdesk ticket has reported that inserting rows in a SQLite database takes too long. I have create a sample app and ran it against both Android and iOS. This is the code: http://pastie.org/private/iar8wglepgcilffp6tnpra">link to the code
And in http://pedruqui.s3.amazonaws.com/20110322222050.png">this image you can see the difference between both platforms in milliseconds after the insert.
Tested Agains iPhone Simulator 4.3 and Android APIs 2.2
Titanium SDK 1.6.1
This is still the case in 1.7.0/upstream.. Any love/fix coming?
Significant time has been invested trying to find a speedup. The underlying implementation seems to be the gating factor. More research will be done, but it won't be fixed in 1.7.0. It may not be fixable.
Any updates on this? Working on a project that could send thousands of insert statements to a user. In an iphone, this takes fractions of a second. In Android this takes quite some time. using 1.8 sdk
using this tip i found on stack overflow: http://stackoverflow.com/questions/1609637/is-it-possible-to-insert-multiple-rows-at-a-time-in-an-sqlite-database. See comments 2 and 3. i was able to cut the time for 10,000 records to about 25 seconds, roughly a 1/3 reduction in time. Which is still significant... but worthwhile to note. I modified the above user's code to support multiple inserts at a time, in 500 blocks. http://pastie.org/3134463 edit: also worth noting that while using this trick, the time for inserts on an iphone went from around 1.3 seconds to about 50ms. Worth using it all around.
Closing due to inactivity. If this issue still exists, please raise a new ticket.