emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Against sqlite3!!!


From: Arthur Miller
Subject: Re: Against sqlite3!!!
Date: Tue, 07 Dec 2021 19:43:30 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Qiantan Hong <qhong@mit.edu> writes:

>>                                                   That would be quite a
>> disadvantage compared to a DB approach where I'd naturally expect that
>> only the value I'm asking for is loaded.

Sqlite does not read one key per request, it reads at least a page. So if your
system uses 64k pages, sqlite will read at least 64k at once. Then you also have
system doing disk i/o, caching nodes and so on; so you are never really getting
just "the value you are asking for to be loaded".

> It does, but I’ve done some benchmark and it loads 10k entries in 0.02~0.03 
> seconds. 100k entries takes <0.5s.
> I’d say it should be suffice for most Emacs application I know of.
> Nobody is using Emacs for trillions of business records.
>
> On the other hand save operation is fully incremental and don’t
> even need to be invoked explicitly.
>
> Being said that, if we really find out loading is not fast enough, I might
> come up with some way to load it in segments lazily. I doubt if that will
> ever become necessary.
>
>> Also, how would it ensure consistency when I have 2 parallel emacs
>> sessions (like one for mail/irc and one for programming/editing) where
>> session 1 modifies the value of key A and the other of key B?  It looks
>> like the values of the kv-store that gets saved later will win.  In case
>> that's the emacs session which has modified B, it'll revert A to the
>> state before the other session modified it, no?
> Since it records a log of deltas instead of printing the whole data structure,
> different key won’t interfere.
>
> Being said that, currently it probably won’t work because UNIX append
> is not atomic and will probably be interleaved into nonsense.
> There’re various workarounds, lock file being one, but I like
> the idea of keeping only one “controller” instance with exclusive
> access to the file more.
You can do same as sqlite does: just lock entire file (db). Sqlite locks entire
db while writes are performed. It can be configured to allow concurrent reads
but only if there are no ongoing writes.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]