On 06/03/17 10:49, Martin Kampas wrote:
Hi Rinigus,

Did you consider this recommendation?

"To simplify matters, SQLite is also available as a pre-packaged amalgamation source code file: sqlite3.c. The amalgamation is a single file of ANSI-C code that implements the entire SQLite library. The amalgamation is much easier to deal with. Everything is contained within a single code file, so it is easy to drop into the source tree of a larger C or C++ program. [...] /For these reasons, the amalgamation source file ("sqlite3.c") is recommended for all applications/."[1]

What are the reasons that prevent you from using the upstream recommended approach? Are they worth your time and effort?


I was always amused by this recommendation. Note that they carefully say "it is easy to drop into the source tree of a LARGER C or C++ program". Even they do understand that it's ridiculous to drop 200k lines of obscure code into a poor little program that just happened to be in need of some database access.

But yeah, if you have written a few million lines of code, adding 200k more is not such a big deal. Still, I would personally prefer to use the system library for the sake of performance, future updates, bug fixes and system-specific tweaks.

Here's a good example - by default sqlite3.c is using up to 2MB+500KB of memory for some sort of cache, meaning that every app that has some use of sqlite would consume at least 2.5MB of heap. That code will never deallocate anything until the buffer fills up, it's that bad. It was quite noticeable on the heap usage graph. We have reduced that to 500KB+125KB and things got better:

https://git.merproject.org/mer-core/sqlite/commit/f132f16b

However, it obviously doesn't affect the apps which have that default 2.5MB limit compiled in. Those will happily continue eating up memory.

I would encourage the developers to use the system sqlite library.

Cheers,
-Slava
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Reply via email to