From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/48597 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: Concerning marks and the back end. Date: Thu, 02 Jan 2003 20:14:30 +0100 Sender: owner-ding@hpc.uh.edu Message-ID: References: <86fzsc4ii2.fsf@asfast.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1041534905 22188 80.91.224.249 (2 Jan 2003 19:15:05 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 2 Jan 2003 19:15:05 +0000 (UTC) Cc: ding@gnus.org Return-path: Original-Received: from hermes.netfonds.no ([80.91.224.195]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18UAo2-0005lf-00 for ; Thu, 02 Jan 2003 20:15:03 +0100 Original-Received: from malifon.math.uh.edu (malifon.math.uh.edu [129.7.128.13]) by hermes.netfonds.no (8.12.1/8.12.1) with ESMTP id h02JFur4017239 for ; Thu, 2 Jan 2003 20:15:57 +0100 (CET) Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 18UAoC-0005mM-00; Thu, 02 Jan 2003 13:15:12 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Thu, 02 Jan 2003 13:16:05 -0600 (CST) Original-Received: from sclp3.sclp.com (sclp3.sclp.com [66.230.238.2]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id NAA24745 for ; Thu, 2 Jan 2003 13:15:51 -0600 (CST) Original-Received: (qmail 5319 invoked by alias); 2 Jan 2003 19:14:42 -0000 Original-Received: (qmail 5314 invoked from network); 2 Jan 2003 19:14:42 -0000 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net (HELO yxa.extundo.com) (217.13.230.178) by 66.230.238.6 with SMTP; 2 Jan 2003 19:14:42 -0000 Original-Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.6/8.12.6) with ESMTP id h02JEURr015474 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Jan 2003 20:14:30 +0100 Original-To: Lloyd Zusman Mail-Copies-To: nobody X-Payment: hashcash 1.1 0:030102:ljz@asfast.com:f853c5f06540e169 X-Hashcash: 0:030102:ljz@asfast.com:f853c5f06540e169 X-Payment: hashcash 1.1 0:030102:ding@gnus.org:96d181624da034a7 X-Hashcash: 0:030102:ding@gnus.org:96d181624da034a7 In-Reply-To: <86fzsc4ii2.fsf@asfast.com> (Lloyd Zusman's message of "Wed, 01 Jan 2003 17:23:17 -0500") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:48597 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:48597 Lloyd Zusman writes: > Since gnus is making use of `.marks' files these days, I'm wondering if > there's a way to solve the following problem that I'm having: > > In some groups, I keep a large history of old messages. Therefore, it > can be very slow to enter such a group. If I want to speed things up, > one thing that I know I could do would be to create some sort of > auxiliary group for each of these groups, wherein I can put most of the > old articles. This way, under normal, everyday use, I can enter the > main group relatively quickly, and those more infrequent times when I > want to look through the old articles, I can go to the auxiliary group. > > But I'm wondering if I can avoid these auxiliary groups. I'm wondering > if there's a mark or set of marks that I can put on articles, and whose > existence would be noted in the .marks file for any given group. And if > so, would it be possible to set up a group so that under normal group > entry, any article ranges that are marked with this special mark will > cause the articles to be ignored with no query being done to the back > end? ... and only if I enter a group in a non-standard way (i.e., via > a different command or a special prefix argument) would these special > marks be ignored and the entire list of articles would be quieried > from the back end. > > This way, I could keep all articles in their original group, with the > oldest articles marked in this special way. Entering the group in the > "normal" manner would be fast, since no back-end query would need to be > done for any articles for which the .marks file indicates the existence > of this special mark. These back-end queries would only be performed > for the non-marked (in this case, newest) articles. > > I hope I explained this clearly. > > Is this something that can now be done in some way, or which perhaps > could be added without a huge amount of complexity? nnvirtual could solve this. But the real problem seem to be why it is taking too long. Maybe that part can be optimized away, e.g. by not querying for articles Gnus can figure out will never be shown in the summary buffer anyway. I added the following to the Troubleshooting chapter, does it help in isolating the slow part? If it is incorrect in any way (written from memory, not tested, etc) please point that out too. Thanks. ,---- | Sometimes, a problem do not directly generate a elisp error but | manifests itself by causing Gnus to be very slow. In these cases, you | can use `M-x toggle-debug-on-quit' and press C-j when things are slow, | and then try to analyze the backtrace (repeating the procedure helps | isolating the real problem areas). A fancier approach is to use the | elisp profiler, ELP. The profiler is (or should be) fully documented | elsewhere, but to get you started there are a few steps that need to be | followed. First, instrument the part of Gnus you are interested in for | profiling, e.g. `M-x elp-instrument-package RET gnus' or `M-x | elp-instrument-packagre RET message'. Then perform the operation that | is slow and press `M-x elp-results'. You will then see which | operations that takes time, and can debug them further. If the entire | operation takes much longer than the time spent in the slowest function | in the profiler output, you probably profiled the wrong part of Gnus. | To reset profiling statistics, use `M-x elp-reset-all'. `M-x | elp-restore-all' is supposed to remove profiling, but given the | complexities and dynamic code generation in Gnus, it might not always | work perfectly. `----