From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/74506 Path: news.gmane.org!not-for-mail From: Dan Christensen Newsgroups: gmane.emacs.gnus.general Subject: Re: Improving Gnus speed Date: Sun, 28 Nov 2010 19:40:23 -0500 Message-ID: <87r5e555e0.fsf@uwo.ca> References: <87zktemkwl.fsf@uwo.ca> <87vd42mdci.fsf@uwo.ca> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1290991255 19740 80.91.229.12 (29 Nov 2010 00:40:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 29 Nov 2010 00:40:55 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M22865@lists.math.uh.edu Mon Nov 29 01:40:49 2010 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PMrnS-0004b2-UG for ding-account@gmane.org; Mon, 29 Nov 2010 01:40:47 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1PMrnM-0004wO-VY; Sun, 28 Nov 2010 18:40:41 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PMrnL-0004w7-23 for ding@lists.math.uh.edu; Sun, 28 Nov 2010 18:40:39 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PMrnJ-00018n-Sv for ding@lists.math.uh.edu; Sun, 28 Nov 2010 18:40:38 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1PMrnJ-0002Sl-00 for ; Mon, 29 Nov 2010 01:40:37 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PMrnG-0004X7-06 for ding@gnus.org; Mon, 29 Nov 2010 01:40:34 +0100 Original-Received: from bas3-london14-1096779322.dsl.bell.ca ([65.95.134.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Nov 2010 01:40:33 +0100 Original-Received: from jdc by bas3-london14-1096779322.dsl.bell.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Nov 2010 01:40:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 25 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: bas3-london14-1096779322.dsl.bell.ca User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:uZI+Z9rNVxrVahQDMRsrRNvrR8g= X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:74506 Archived-At: Francis Moreau writes: > Francis Moreau writes: > >> Hmm, I'm wondering if sorting the 'children' for a given thread is >> really important. I would say that I could live without it I think >> specially if it makes group entering faster. > > Indeed changing the definition of gnus-sort-threads-recursive like the > following: > > (defun gnus-sort-threads-recursive (threads func) > (sort threads func)) > > make the sorting time almost null. In my tests, if one of the sort functions is gnus-thread-sort-by-most-recent-date, then the above takes almost as long as sorting all of the children too, since it needs to convert *all* time strings to emacs times, and that dominates. As you pointed out, the real thing to investigate is the rest of the time taken for summary buffer generation. Any takers? Dan