From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexandre Garreau Newsgroups: gmane.emacs.devel Subject: Re: sqlite3 Date: Wed, 15 Dec 2021 03:09:21 +0100 Message-ID: <2563341.DJk1cxha8W@galex-713.eu> References: <87tufmjyai.fsf@gnus.org> <87lf0nr2b4.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13007"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 15 03:10:55 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mxJks-00032f-Co for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Dec 2021 03:10:54 +0100 Original-Received: from localhost ([::1]:48688 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mxJkq-0006AI-VU for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Dec 2021 21:10:52 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:46086) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxJjd-0005M5-BB for emacs-devel@gnu.org; Tue, 14 Dec 2021 21:09:37 -0500 Original-Received: from [2a00:5884:8305::1] (port=36488 helo=galex-713.eu) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxJjT-0006A3-Pc for emacs-devel@gnu.org; Tue, 14 Dec 2021 21:09:33 -0500 Original-Received: from gal by galex-713.eu with local (Exim 4.94.2) (envelope-from ) id 1mxJjO-002smg-7s; Wed, 15 Dec 2021 03:09:22 +0100 In-Reply-To: <87lf0nr2b4.fsf@gnus.org> X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:5884:8305::1 (failed) Received-SPF: pass client-ip=2a00:5884:8305::1; envelope-from=galex-713@galex-713.eu; helo=galex-713.eu X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:281964 Archived-At: Le mardo, 14-a de decembro 2021, 9-a horo kaj 57:51 CET Lars Ingebrigtsen=20 a =C3=A9crit : > Lars Ingebrigtsen writes: >=20 >=20 > > I think it'd be good to bring that into core, and then write a small > > wrapper library (well, a trivial ORM) for the rest of Emacs to use, so > > that we don't have to write SQL all over the place. That is: > >=20 > > (setf (persistent-data :namespace "emoji" :key "favorites") > > emoji--favorites) > >=20 > > I.e., what Emacs needs is a persistent key/value store, and this would > > give us that. >=20 > This is now implemented under the name of `multisession-value' (but not > merged to the trunk yet; I'll probably do that later today, unless > somebody comes up with a better name). >=20 > As for the sqlite part of this: My initial benchmarking of this was > wrong. I thought sqlite3 was going to be a real advantage for this > thing, since I'd benchmarked excellent performance (more than 50K > updates per second, for instance). But that's only when not committing > after every transaction, which we want to do here, really. >=20 > But it turns out that sqlite3 is actually slower for this particular use > case than just writing the data to a file (i.e., using the file system > as the database; one file per value). So multisession.el now offers > two backends (`files' and `sqlite'), and defaults to `files'. What about having an intermediary abstraction for persistent stores in=20 general, and on top of that multisession variables? What about a all-variables-in-one-file very trivial backend? a gdbm=20 backend? would that be possible/allowable if gdbm is only integrated as a=20 module? What fs did you benchmark with? did you try with an old-linked-list-like=20 ext4, or a modern btree btrfs? I think the later might (unportably,=20 though) display some advantages that sqlite (portably) provides. gdbm might provide some others. I would find benchmarking of all these=20 relevant and interesting (and why not of qiantan=E2=80=99s incremental=E2= =80=99s store as=20 well, if he integrates it)