From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: persistent data feature Date: Sat, 11 Dec 2021 09:26:56 -0800 Message-ID: <87sfuz128v.fsf@ericabrahamsen.net> References: <87tufmjyai.fsf@gnus.org> <877dcil2sj.fsf@ericabrahamsen.net> <87czm98qi1.fsf@gnu.org> <87o85tcwm0.fsf@ericabrahamsen.net> <874k7ljwkr.fsf@gnus.org> <87fsr5cuzq.fsf@ericabrahamsen.net> <878rwx8mdn.fsf@gnu.org> <87r1aphuei.fsf@gnus.org> <837dcex6ub.fsf@gnu.org> <87bl1p10js.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27631"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Richard Stallman , cesar.mena@gmail.com, emacs-devel@gnu.org, Pip Cet , Lars Ingebrigtsen , eliz@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 11 18:27:51 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 1mw6A2-00070V-Qw for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Dec 2021 18:27:51 +0100 Original-Received: from localhost ([::1]:56208 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mw6A1-0007Op-6O for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Dec 2021 12:27:49 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56610) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mw69O-0006kU-LO for emacs-devel@gnu.org; Sat, 11 Dec 2021 12:27:10 -0500 Original-Received: from mail.ericabrahamsen.net ([52.70.2.18]:60752) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mw69L-0005Vj-A2; Sat, 11 Dec 2021 12:27:09 -0500 Original-Received: from localhost (c-71-197-232-41.hsd1.wa.comcast.net [71.197.232.41]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 50E61FA08F; Sat, 11 Dec 2021 17:26:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1639243618; bh=crGL2XClTqus7WFJzMKh8CuqvWsKxZ1pwS1K8OuoVNk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=sO/gpOpO2zBWeJBkFxqooQHBXTwBi7CiyWkQ5diQGqgpXfahbWPAbNdT/JNr+uDlD AcwMYxXR8hDHCdcFNDgMicUopwA9OkDTcxLMsZNUUL/SQpuRFdnGj6jcWUHMcNjNSA S9Mih28Szbt3vUxan8yszjd5xDHj2XWPZO2uBfz0= In-Reply-To: (Stefan Monnier's message of "Fri, 10 Dec 2021 07:58:56 -0500") Received-SPF: pass client-ip=52.70.2.18; envelope-from=eric@ericabrahamsen.net; helo=mail.ericabrahamsen.net X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:281697 Archived-At: Stefan Monnier writes: >>> If we provide a feature for storing persistent Lisp data, I contend >>> that the default option should be to store it in a purely textual file. >>> >>> Many users will not store large amounts of data, and a textual file >>> would be much less risk-prone than any other method. >> >> There will, of course, be large amounts of data, and that will be slow. >> (People already do this with a number things, and the results are >> predictably sluggish.) > > To help me understand this discussion, I think it would help me to have > examples of such large databases currently implemented as text files, > along with an idea of what "large" means in this context (how many MBs) > and where the "slow"ness manifests itself. FWIW I would also provide a sqlite backend for EBDB (contact management). Not because the eieio-persistent text files are large (my 3200 contacts take up 1.5M), but because I'd like to let users make use of that data in other, non-Emacs applications. I would also be looking at a usage pattern that does not slurp the whole database into memory at startup. Probably it would build some minimal caches at startup, and then access the database for reads and writes as necessary.