From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Noah Friedman Newsgroups: gmane.emacs.devel Subject: Re: IRC client for Emacs Date: Wed, 21 Aug 2002 19:39:00 -0700 (PDT) Sender: emacs-devel-admin@gnu.org Message-ID: <20020821193900.557945.FMU965@piglet.prv.splode.com> References: <873ctot40n.fsf@emacswiki.org> <20020809223753.955308.FMU31823@piglet.prv.splode.com> <200208110355.g7B3tOo06247@wijiji.santafe.edu> <877kixtg8w.fsf@emacswiki.org> <20020811160610.424772.FMU9022@piglet.prv.splode.com> <87fzxhs1ia.fsf@emacswiki.org> <200208151954.g7FJsut07968@wijiji.santafe.edu> <20020820143817.816033.FMU965@piglet.prv.splode.com> <200208210153.g7L1r4W10188@wijiji.santafe.edu> <20020820190744.375246.FMU965@piglet.prv.splode.com> <200208220156.g7M1uvx10414@wijiji.santafe.edu> Reply-To: Noah Friedman NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1029984103 14628 127.0.0.1 (22 Aug 2002 02:41:43 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 22 Aug 2002 02:41:43 +0000 (UTC) Cc: alex@emacswiki.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17hhun-0003np-00 for ; Thu, 22 Aug 2002 04:41:41 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17hiNU-0005ON-00 for ; Thu, 22 Aug 2002 05:11:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17hhvy-0002Em-00; Wed, 21 Aug 2002 22:42:54 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17hhsI-0001rW-00 for emacs-devel@gnu.org; Wed, 21 Aug 2002 22:39:06 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17hhsG-0001ov-00 for emacs-devel@gnu.org; Wed, 21 Aug 2002 22:39:06 -0400 Original-Received: from scones-of-silence.splode.com ([216.27.180.143] helo=piglet.prv.splode.com) by monty-python.gnu.org with esmtp (Exim 4.10) id 17hhsF-0001lZ-00; Wed, 21 Aug 2002 22:39:04 -0400 Original-Received: (from friedman@localhost) by piglet.prv.splode.com (8.9.3/8.9.3) id TAA20910; Wed, 21 Aug 2002 19:39:00 -0700 Original-To: rms@gnu.org In-Reply-To: <200208220156.g7M1uvx10414@wijiji.santafe.edu> (rms@gnu.org Wednesday, 21 Aug 2002 19:56:57 -0600) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:6751 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6751 > What do you think about providing persistent hashtables, via gdbm or > berkeley db? > >It is not completely out of the question, but it sounds awfully >heavyweight. Sinc ethis does need to run particularly fast, >we ought to be able to do something more simpler, using text >files directly. The solutions that come to mind involve generating a separate index for those files and writing the lookup and loading routines in elisp. This is ok, but the disadvantages I see to that are: * it's another special-purpose API * Since the data is plain text, you either have to read the whole file into memory to scan for the relevant data, or else generate a separate index file. Index files would need to be regenerated when the plain text file changes, so you have to check for this condition somewhere. The other alternative is to have a separate message per-file, but then performance is dependent on the implementation of the filesystem. For example ext2fs has linear directory tables but xfs has b-tree indexed tables; so file name resolution on the former, especially in large directories, is slower. * all the routines for lookup and index generation would be in elisp, which is slower than adding C calls to gdbm/dbd. Persistent hashtables might be useful for other things (such as BBDB), so they seem worth considering for reasons beyond localization. For applications which frequently access the same data, they can cache it. Perhaps that could even be a feature of hashtables which open the diskfile in read-only mode, but in any case you could just copy values to a non-persistent hash.