Richard Hipp <d...@sqlite.org> 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.
It depends of course, but for my project, saving 72KB of memory per connection is more important as many databases are opened, each consuming memory. It may be an unusual scenario though. Furthermore, since I set a heap soft limit for SQLite, saving memory per connection should leave more memory for page caching, hence more SQLite page cache hits, hence less I/Os. In any case, if user can choose at compile time or runtime, the default behavior does not matter for me. I'm curious about what kind of change reduces memory per connection. Regards Dominique _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
