From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: persistent data feature Date: Fri, 10 Dec 2021 09:37:20 -0500 Message-ID: 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> <87a6h8y5j6.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="23460"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Richard Stallman , eric@ericabrahamsen.net, cesar.mena@gmail.com, eliz@gnu.org, Pip Cet , emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 10 15:38:37 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 1mvh2j-0005wY-As for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Dec 2021 15:38:37 +0100 Original-Received: from localhost ([::1]:34462 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mvh2i-0000Hm-1u for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Dec 2021 09:38:36 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49790) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvh1d-0007N7-0w for emacs-devel@gnu.org; Fri, 10 Dec 2021 09:37:29 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56653) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvh1Z-00041S-T9; Fri, 10 Dec 2021 09:37:28 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 629264408F6; Fri, 10 Dec 2021 09:37:23 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CB692440630; Fri, 10 Dec 2021 09:37:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1639147041; bh=qV/j8fN+Bq2eRS/cvqLQ/MCCKFCfTLDMy/6GBKJwXZU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=SP5OxpkFA3BKqk93B5Eabs1Z9dEjxh9k7jyfK2bPkY1FsZsaou2wO7erxdd/8MJ34 lXAhOIf+tdfbyI54VSXQu+7KZyQ7IzQCx3kMjfty/BAsDde/4DmB42byhb02UHnhwj pz+wmDqEnZwcEbZsggPWjrBQYPajciE2cWuJ4AEbPh4tMARWbwgj6Cz/ok9HmVgdFl x81QcbCuaOj/brJDrlhvSMYzoVaPiyyg1snQgtmyQSgnJENQFi9YVou9ln2CXGOhKR v4qjFrCrUQbar2ptZGrVEWnl4LVv1o57cvZd1ryNEYcpZaXdpZd7cO7QyX49+rWvae TYQw+2HVoL6Ng== Original-Received: from pastel (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8AAD612081A; Fri, 10 Dec 2021 09:37:21 -0500 (EST) In-Reply-To: <87a6h8y5j6.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 10 Dec 2021 14:05:01 +0100") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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:281600 Archived-At: > But the current large data structures are in things like the Gnus > registry, which can grow arbitrarily large (and slow, unless you trim > it). And my .ecompleterc is 4MB. 4MB doesn't sound like it should be a problem, and I don't see much benefit in having ecompleterc grow much further (by its nature it contains a lot of "irrelevant" data and it's good to trim it every once in a while for that reason). Also having it too large would slow down completion itself, so I suspect that storing it in a sql database would not help. The gnus-registry is a much more compelling example (especially since there's no reason we should regularly scan it from start to end, we only really ever need to look up specific entries, so the indexing of the database should allow answering those queries efficiently without having to read the whole DB from the disk (tho nowadays reading 100MB from the disk is basically instantaneous anyway). So, IIRC the only current example is gnus-registry. That sounds good. Stefan