From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: What's the problem? Date: Thu, 11 Dec 2003 13:39:39 -0500 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <4nu147ryfo.fsf@collins.bwh.harvard.edu> 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> Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUVlE-0005vP-00 for ; Thu, 11 Dec 2003 19:42:04 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUVlE-0006FL-00 for ; Thu, 11 Dec 2003 19:42:04 +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 1AUWiG-00057M-Pw for emacs-devel@quimby.gnus.org; Thu, 11 Dec 2003 14:43:04 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AUWhu-00053w-P5 for emacs-devel@gnu.org; Thu, 11 Dec 2003 14:42:42 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AUWhN-0004ts-4E for emacs-devel@gnu.org; Thu, 11 Dec 2003 14:42:41 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AUWhM-0004t3-Mn for emacs-devel@gnu.org; Thu, 11 Dec 2003 14:42:08 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AUVju-0006tn-00 for ; Thu, 11 Dec 2003 19:40:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUVjr-0006tf-00 for ; Thu, 11 Dec 2003 19:40:39 +0100 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AUVjr-0006yZ-00 for ; Thu, 11 Dec 2003 19:40:39 +0100 Original-Lines: 63 Original-X-Complaints-To: usenet@sea.gmane.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (usg-unix-v) Cancel-Lock: sha1:ktdCAHt9c5AIK3EbyaJlIALEyZg= 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:18642 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18642 On 11 Dec 2003, miles@lsi.nec.co.jp wrote: > Ted Zlatanov writes: >> > 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'll list the pieces I know best. There are probably others. - getting new mail, read/write existing mail - interacting with network backends - nnimap: medium read, slow write - nntp: fast read - nnrss: slow initial read - interacting with local backends: nnml, nnmaildir, etc. - spam-splitting - sending mail - building summary buffers - retrieving articles from overview data - scoring - building threads - spam-splitting (for backends that don't get new mail, e.g. nntp) - detecting and processing spam - recognizing spam (connects with spam-splitting above) - remembering spam with internal or external programs - tracing article threads back to a folder (gnus-registry) - look up registry hashtable, look through a list for each reference ID and examine each cell closely - look up, modify, and store back registry hashtable entry >> > 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. I'll be the first one in line if those changes ever happen. Thanks Ted