From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: Against sqlite3!!! Date: Tue, 07 Dec 2021 20:34:38 +0100 Message-ID: <87wnkg5fvo.fsf@gnu.org> References: <41E1B5BD-879C-430C-8BA3-3A5354AF2928@mit.edu> <87tufkwga9.fsf@gnu.org> <28E143D2-5C8F-4CDC-B6CE-15F672A00AB1@mit.edu> 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="8105"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.5; emacs 29.0.50 Cc: emacs-devel@gnu.org, Zhu Zihao , Stefan Monnier To: Qiantan Hong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 07 21:19:29 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 1mugvx-0001rP-FT for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Dec 2021 21:19:29 +0100 Original-Received: from localhost ([::1]:58466 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mugvv-0000lm-WE for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Dec 2021 15:19:28 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60590) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mugu9-0006zq-7B for emacs-devel@gnu.org; Tue, 07 Dec 2021 15:17:37 -0500 Original-Received: from [2001:470:142:3::e] (port=56698 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mugu8-0004r2-26; Tue, 07 Dec 2021 15:17:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-reply-to:Date:Subject:To:From: References; bh=XlqTciSfmT4nMiEppxN1QQcJnuPHKV5qzT4d6bskFHc=; b=D/xFsbDJFc8uTq b5XV2yPkCR2PWpyNG9ogBYeGsLuKPw4vx1lYVo3zWDGAHQDcpqkVuJKlO9hTR7oe4KW71aSrlw4wR 9469HFT3ak3D1213oOloiak/0sFut7b0rOfeTy0qXYRMF9H2xDcod8NNnH/kBTEzIIyc7Nb8CXUX0 WczMLznKk3vX9RDZV0ircYKHnG6qIhS13vHC7ViIqEO9T8wWfrc8SxSz6GrRIyflm7ZH2PW7CqaxS ormkWpDkrORY69Jom6SxY0G4q/evhNiKj1nkAVZczUMfh9V97LTFew+1sbUDe1mNGTp01Kx0an/Jx G6G8RWRt99gVU43Lfhrg==; Original-Received: from auth2-smtp.messagingengine.com ([66.111.4.228]:59025) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mugu8-0005Vy-4e; Tue, 07 Dec 2021 15:17:36 -0500 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 52F5D27C0054; Tue, 7 Dec 2021 15:17:35 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 07 Dec 2021 15:17:35 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjeehgddufeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfhgfhffvufffjgfkgggtgfesthhqredttderjeenucfhrhhomhepvfgrshhs ihhlohcujfhorhhnuceothhsughhsehgnhhurdhorhhgqeenucggtffrrghtthgvrhhnpe eiudfghffhjeevvedvhfffgeetleeljefffeeggfeugeegleehfeeiueejhfehgeenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhorhhnod hmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdekieejfeekjeekgedqieefhedv leekqdhtshguhheppehgnhhurdhorhhgsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 7 Dec 2021 15:17:34 -0500 (EST) In-reply-to: <28E143D2-5C8F-4CDC-B6CE-15F672A00AB1@mit.edu> 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:281278 Archived-At: Qiantan Hong writes: >> I'm not very knowledgable with cl-* stuff but doesn't your >> implementation load all key-value pairs at once? 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. > It does, but I=E2=80=99ve done some benchmark and it loads 10k entries in > 0.02~0.03 seconds. 100k entries takes <0.5s. But your values are very only small lists. > I=E2=80=99d say it should be suffice for most Emacs application I know of. > Nobody is using Emacs for trillions of business records. I'd imagine that if such a feature became available, packages would start using it and store more data that they do now for whatever reasons. Like eww/elpher could want to store the list of the last 100 visited URLs. >> 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=E2=80=99t interfere. Ah, allright. By skimming the code I've first thought the log would only be for analysis/debugging purposes. > Being said that, currently it probably won=E2=80=99t work because UNIX ap= pend > is not atomic and will probably be interleaved into nonsense. > There=E2=80=99re various workarounds, lock file being one, but I like the= idea > of keeping only one =E2=80=9Ccontroller=E2=80=9D instance with exclusive = access to the > file more. Interesting, but how would emacs instances interact with that controller instance? And would that controller instance simply be the first emacs instance of a user? What if the controller blocks because Gnus is running and currently downloading mails with huge attachments? >> If that were true, I'd say your resist!.el is a non-starter in the >> current form. It should at least load only values explicitly asked for >> and only persist/override actually changed values. A trivial solution >> could use one file per key. Not sure how sensible that is. > It does the latter. No, it uses one file per kv-store but you can have as many kv-stores as you like, e.g., one per package. Or do you mean "it only overrides changed values" with "the latter"? Indeed, that's true. I've played with the code and now understand it. Nice! :-) (kv-rem is missing a kv-store arg.) > As I=E2=80=99ve mentioned, from the benchmark results, the former doesn= =E2=80=99t > seem to be a big problem. You=E2=80=99ll do it at most once for every Ema= cs > instance anyway. Yeah, and since it's no global store in the sense of "every package feeds its data into the same store", my argument is void. If my emacs session doesn't start Gnus, Gnus won't load its own store. Bye, Tassilo