Give me speed anytime and twice on Sundays... ________________________________ From: sqlite-users <sqlite-users-boun...@mailinglists.sqlite.org> on behalf of Eric Grange <zar...@gmail.com> Sent: Saturday, December 14, 2019 04:11 PM To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Subject: Re: [sqlite] Performance vs. memory trade-off question
While I am using SQLIite mostly in x86-64 with plentiful RAM, I suspect the reduced lookaside size will help CPU L1/L2 caches, which is definitely never plentiful. I would not be surprised if it resulted in a speedup in practical high-load multi-threaded scenarios. Also future SQLite code changes may be able to further build upon a new lookaside configuration by tweaking the structure sizes to more tightly match with the slot sizes f.i., and reduce the performance hit even in single-threaded cases. So "on by default" for me. Eric Le sam. 14 déc. 2019 à 14:27, Richard Hipp <d...@sqlite.org> a écrit : > 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. > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users