I apologize in advance if this is the wrong place to report bugs with the SQLite Android bindings, but I couldn’t figure out how to file a ticket on that subsite (https://sqlite.org/android/) and didn’t see any contact information there, so I figured I’d try here.
Query performance, particularly for large result sets, is significantly worse (by up to an order of magnitude) when using the SQLite Android bindings than with AOSP SQLite, even for completely identical data. This slowness originates from the bindings’ nativeExecuteForCursorWindow implementation, which uses JNI in a loop because the much faster C++ methods the AOSP uses are private. This is responsible for the entire performance difference. I understand that this is the only way for the bindings to manipulate CursorWindows from C++, but this is too big a downside to be mentioned only in code comments (https://www.sqlite.org/android/artifact/afd8e719c44fb86f), and obliquely at that. It’s a systematic scalability issue and should be called out clearly, in the “Differences From the Built-in SQLite Support” section here (https://www.sqlite.org/android/doc/trunk/www/usage.wiki) or even on the bindings’ home page, given the severity of the difference. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
