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
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
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
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
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/
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
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
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:
>
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
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
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
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
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
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
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)
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
16 matches
Mail list logo