From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: What's the problem? Date: 11 Dec 2003 10:46:01 +0900 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <4nllpt3hr3.fsf@lockgroove.bwh.harvard.edu> <5bad69zd43.fsf@lister.roxen.com> <4noeuon378.fsf@lockgroove.bwh.harvard.edu> <4ny8tsgxy6.fsf@lockgroove.bwh.harvard.edu> <4nhe0ggv0u.fsf@lockgroove.bwh.harvard.edu> <4nk75bwjaf.fsf@lockgroove.bwh.harvard.edu> <4nsmjv8d32.fsf@collins.bwh.harvard.edu> <87iskpbloe.fsf@mail.jurta.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1071107255 1458 80.91.224.253 (11 Dec 2003 01:47:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 11 Dec 2003 01:47:35 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Dec 11 02:47:32 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUFvQ-00039M-00 for ; Thu, 11 Dec 2003 02:47:32 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUFvP-0005Kq-00 for ; Thu, 11 Dec 2003 02:47:32 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AUGsP-0000h4-Nz for emacs-devel@quimby.gnus.org; Wed, 10 Dec 2003 21:48:29 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AUGs6-0000gm-2f for emacs-devel@gnu.org; Wed, 10 Dec 2003 21:48:10 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AUGra-0000aG-8e for emacs-devel@gnu.org; Wed, 10 Dec 2003 21:48:09 -0500 Original-Received: from [202.32.8.214] (helo=TYO201.gate.nec.co.jp) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AUGrZ-0000Zx-Kd; Wed, 10 Dec 2003 21:47:37 -0500 Original-Received: from mailgate3.nec.co.jp ([10.7.69.186]) by TYO201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id hBB1k3c16755; Thu, 11 Dec 2003 10:46:04 +0900 (JST) Original-Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id hBB1k3001408; Thu, 11 Dec 2003 10:46:03 +0900 (JST) Original-Received: from edtmg01.lsi.nec.co.jp ([10.26.16.201]) by mailsv3.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id hBB1k2L25314; Thu, 11 Dec 2003 10:46:02 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp (localhost [127.0.0.1]) by edtmg01.lsi.nec.co.jp (8.9.3p2+3.2W/3.7W_EDC_Ver.1.0) with ESMTP id KAA27611; Thu, 11 Dec 2003 10:46:02 +0900 (JST) Original-Received: from localhost (mcspd15 [10.30.114.174]) by mcsss2.ucom.lsi.nec.co.jp (8.12.10/8.12.8/EDcg v2.01-mc/1046780839) with ESMTP id hBB1k17Q001822; Thu, 11 Dec 2003 10:46:01 +0900 (JST) Original-Received: by localhost (Postfix, from userid 31295) id 71DCC10097; Thu, 11 Dec 2003 10:46:01 +0900 (JST) Original-To: Ted Zlatanov System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <4nzne0n0q1.fsf@collins.bwh.harvard.edu> Original-Lines: 59 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18628 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18628 Ted Zlatanov writes: > > IOW, it's annoying for the gnus programmer, but very easy for the > > emacs implementation. > > Well, that's the rub, isn't it? Simon and I, being Gnus programmers, > would like Emacs to provide something better than the current > framework so the pain will be spread out instead of concentrated on > us. I think that improvements to Emacs would be beneficial to far > more people than improvements to Gnus, also. Of course. It's just that past a certain point (e.g. providing _real_ threading), the changes to emacs are insanely complex and intrusive. The sort of awkward `pseudo-threading' framework I gave an example of, although it's annoying for the application programmer, is I think relatively _less_ annoying than the sort of massive emacs changes required for true threading. If the number of places where you really _need_ it are fairly few, I think it makes more sense to put the complexity in those places. My impression is that this is the case; indeed, for me it's basically like 2-3 operations in gnus, and that's it (most other time-consuming commands use external processes in the background to do their work). Now, any of my assumptions could be wrong, in which case maybe the calculation is different, but... > > Some questions are (1) are there only a few points within gnus that > > represent most of the annoying delays > > Hashtable lookups, list traversals, and arithmetic. Those three show > up all over the place, and they are generally not mutually dependent > when done on separate articles. No, that's not what I meant -- those sorts of operations may in aggregate represent the bulk of the cpu time spent, but no single operation actually takes very long. I'm more concerned with what entry points into gnus (I mean, user commands) hang for a long time. Find those, and if there are only a few of them, see if they can be split up using a pseudo-threading framework or something. > > I don't know. A framework like the above could pretty simply handle > > the I/O bound portion too, though. > > Remember the auto-save (over NFS or Tramp) problem I mentioned. I > don't think it can be done the way you propose, but I'll be happy to > be proven wrong. Sure; I hate auto-save delays too (even more annoying is the !@#$%! purposeful-delay-to-give-an-error-message autosave does when it can't write a file), but I suppose fixing them would require low-level changes to emacs. -Miles -- `There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy.'