From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/8120 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.gnus.general Subject: Re: Long time to exit summary buffer, possible speed enhancement? Date: 30 Sep 1996 11:57:43 -0400 Sender: raeburn@cygnus.com Message-ID: References: <199609291309.OAA29461@gandalf.uio.no> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035148333 10225 80.91.224.250 (20 Oct 2002 21:12:13 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:12:13 +0000 (UTC) Cc: ding@ifi.uio.no Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.6/8.6.9) with SMTP id JAA30309 for ; Mon, 30 Sep 1996 09:34:54 -0700 Original-Received: from cygnus.com (cygnus.com [140.174.1.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 30 Sep 1996 17:59:22 +0200 Original-Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1]) by cygnus.com (8.6.12/8.6.9) with SMTP id IAA11153; Mon, 30 Sep 1996 08:57:48 -0700 Original-Received: from cujo.cygnus.com by tweedledumb.cygnus.com (4.1/4.7) id AA07214; Mon, 30 Sep 96 11:57:46 EDT Original-Received: by cujo.cygnus.com; (5.65v3.2/1.1.8.2/20Sep95-0235PM) id AA10142; Mon, 30 Sep 1996 11:57:43 -0400 Original-To: Steinar Bang In-Reply-To: Steinar Bang's message of 30 Sep 1996 07:37:15 +0100 Original-Lines: 22 X-Mailer: Red Gnus v0.45/Emacs 19.33 Xref: main.gmane.org gmane.emacs.gnus.general:8120 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:8120 Steinar Bang writes: > In those newsgroup, with big gaps, I see slow startup time (slow for > the number of articles unmarked + number of new). > > Are there any traces I can make to find out where it uses its time? As Lars said earlier in this thread: > Anyways, range handling isn't all that slow, so the ~10 second delay > probably is caused by something else. Try `(setq debug-on-quit t)' > and then `C-g' when things "hang" (sorta). The resulting backtrace > should tell you which function is being slow. I recommend doing this but hitting C-g a few times during the slow bits. If it's in the same code most of the time you trap into the debugger, that's a more convincing case for that code being the time sink. If you do it only once, you could get a traceback in a part that's actually very efficient if your timing happens to be poor. Ken