I'd lean towards speed being preferable in the default. Reasoning:
* People who use SQLite in low-RAM (i.e. embedded) scenarios compile it themselves.
* People who use it on PCs (like me) almost never compile it, they just use whatever the distro/sqlite.org/language-of-choice provides, and that in turn uses the default.
The default therefore is much more likely to affect the later user than the former. 74kB of RAM on a machine that has some multiple of ~4,000,000kB of RAM is a rounding error.
Add a note to the docs page about "low RAM use notes" for those who need to know (I'm guessing there is such a page; never looked for it).
My 2p, Jonathan On 2019-12-14 13:27, Richard Hipp wrote:
A new feature on a branch has the following disadvantages: (1) It uses about 0.25% more CPU cycles. (Each release of SQLite is normally about 0.5% faster, so enabling this feature is sort of like going back by one-half of a release cycle.) (2) The code space (the size of the library) is between 400 and 500 bytes larger (depending on compiler and optimization settings). The this one advantage: (3) Each database connection uses about 72 KB less heap space. QUESTION: Should this feature be default-on or default-off? What's more important to you? 0.25% fewer CPU cycles or about 72KB less heap space used per database connection? The feature can be activated or deactivated at start-time, but you take the disadvantages (the performance hit and slightly larger library size) regardless, unless you disable the feature at compile-time. If the feature is compile-time disabled, then the corresponding code is omitted and and it cannot be turned on at start-time. If you have opinions, you can reply to this mailing list, or directly to me.
_______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
