Re: [sqlite] Performance vs. memory trade-off question

2019-12-24 Thread Jonathan Moules
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

Re: [sqlite] Performance vs. memory trade-off question

2019-12-16 Thread Nelson, Erik - 2
Dominique Devienne wrote on Monday, December 16, 2019 7:46 AM >On Sat, Dec 14, 2019 at 2:27 PM Richard Hipp wrote: >> 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

Re: [sqlite] Performance vs. memory trade-off question

2019-12-16 Thread Jose Isaias Cabrera
Give me speed anytime and twice on Sundays... From: sqlite-users on behalf of Eric Grange Sent: Saturday, December 14, 2019 04:11 PM To: SQLite mailing list Subject: Re: [sqlite] Performance vs. memory trade-off question While I am using SQLIite mostly

Re: [sqlite] Performance vs. memory trade-off question

2019-12-16 Thread Dominique Devienne
On Sat, Dec 14, 2019 at 2:27 PM Richard Hipp wrote: > 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? > Backward compatibility. I.e. if I change nothing in my

Re: [sqlite] Performance vs. memory trade-off question

2019-12-15 Thread Andy Bennett
Hi, (3) Each database connection uses about 72 KB less heap space. How much is this as a percentage of a freshly initialised connection and how much as a percentage of some kind of "typical" connection (is there even one?)? andy...@ashurst.eu.org http://www.ashurst.eu.org/

Re: [sqlite] Performance vs. memory trade-off question

2019-12-14 Thread Simon Slavin
On 14 Dec 2019, at 8:49pm, Donald Shepherd wrote: > Gut feel is that the divide will fall such that embedded use cases want the > memory and PC or equivalent use cases want the CPU. I read here around 18 months ago that more than half of SQLite installations were on mobile phones (presumably

Re: [sqlite] Performance vs. memory trade-off question

2019-12-14 Thread Eric Grange
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

Re: [sqlite] Performance vs. memory trade-off question

2019-12-14 Thread Donald Shepherd
On Sun, 15 Dec 2019 at 1:40 am, Dominique Pellé wrote: > Richard Hipp wrote: > > > On 12/14/19, Dominique Pellé wrote: > > > > > > I'm curious about what kind of change reduces memory per > > > connection. > > > > > > > The branch is here: >

Re: [sqlite] Performance vs. memory trade-off question

2019-12-14 Thread Dominique Pellé
Richard Hipp wrote: > On 12/14/19, Dominique Pellé wrote: > > > > I'm curious about what kind of change reduces memory per > > connection. > > > > The branch is here: > https://www.sqlite.org/src/timeline?r=mini-lookaside-take-2 > > I'll try to add more description later - busy with other

Re: [sqlite] Performance vs. memory trade-off question

2019-12-14 Thread Esdras Mayrink
I think it should be turned on by default. Saving 72KB per connection is worth the performance penalty. On Sat, Dec 14, 2019 at 11:22 AM Dominique Pellé wrote: > Richard Hipp wrote: > > > A new feature on a branch has the following disadvantages: > > > > (1) It uses about 0.25% more CPU

Re: [sqlite] Performance vs. memory trade-off question

2019-12-14 Thread Richard Hipp
On 12/14/19, Richard Hipp wrote: > On 12/14/19, Dominique Pellé wrote: >> >> I'm curious about what kind of change reduces memory per >> connection. >> > > The branch is here: > https://www.sqlite.org/src/timeline?r=mini-lookaside-take-2 > > I'll try to add more description later - busy with

Re: [sqlite] Performance vs. memory trade-off question

2019-12-14 Thread Richard Hipp
On 12/14/19, Dominique Pellé wrote: > > I'm curious about what kind of change reduces memory per > connection. > The branch is here: https://www.sqlite.org/src/timeline?r=mini-lookaside-take-2 I'll try to add more description later - busy with other things right this moment. -- D. Richard Hipp

Re: [sqlite] Performance vs. memory trade-off question

2019-12-14 Thread Dominique Pellé
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

Re: [sqlite] Performance vs. memory trade-off question

2019-12-14 Thread Gary R. Schmidt
On 15/12/2019 00: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

Re: [sqlite] Performance vs. memory trade-off question

2019-12-14 Thread Philip Bennefall
Hi Richard, I can see the advantage of both, but personally I prefer the greater speed with slightly more memory approach (e.g. what we have now). Kind regards, Philip Bennefall On 12/14/2019 2:27 PM, Richard Hipp wrote: A new feature on a branch has the following disadvantages: (1)

[sqlite] Performance vs. memory trade-off question

2019-12-14 Thread Richard Hipp
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