Re: Concerning marks and the back end.

[Simon Josefsson <jas@extundo.com>]

Lloyd Zusman <ljz@asfast.com> 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.
`----