Re: strange memory usage for nntp groups

[Emanuel Berg <moasen@zoho.com>]

Eric S Fraga wrote:

> Ah, interesting; it could be.
> My gmane.linux.debian.user overview file, for
> instance, is 162Mb!
>
> Is there a solution? What if I delete the
> overview file? Will having it regenerate lead
> to the same size?

From what I can understand from the manual
entry, yanked last in this posts, the overview
files are generated by Gnus only for nnml; for
NNTP, the server makes them, so I suppose
additions are communicated and
appended locally.

If so, deleting a file will help but eventually
it will grow back to size.

Also, what functionality will be *lost* this
way? The ability to access old posts?

In general, the purpose of the overview files
isn't clear to me from the manual entry.
It seems to be some scheme with the purpose,
interestingly, to speed up populating the
summary buffer!


"NOV"
     NOV stands for News OverView, which is
     a type of news server header which provide
     datas containing the condensed header
     information of articles. They are produced
     by the server itself; in the ‘nntp’ back
     end Gnus uses the ones that the NNTP
     server makes, but Gnus makes them by
     itself for some backends (in particular,
     ‘nnml’).

     When Gnus enters a group, it asks the back
     end for the headers of all unread articles
     in the group. Most servers support the
     News OverView format, which is more
     compact and much faster to read and parse
     than the normal HEAD format.

     The NOV data consist of one or more text
     lines (*note Motion by Text Lines:
     (elisp)Text Lines.) where each line has
     the header information of one article.
     The header information is a tab-separated
     series of the header’s contents including
     an article number, a subject, an author,
     a date, a message-id, references, etc.

     Those data enable Gnus to generate summary
     lines quickly. However, if the server does
     not support NOV or you disable it
     purposely or for some reason, Gnus will
     try to generate the header information by
     parsing each article’s headers one by one.
     It will take time. Therefore, it is not
     usually a good idea to set nn*-nov-is-evil
     (*note Slow/Expensive Connection::) to
     a non-‘nil’ value unless you know that the
     server makes wrong NOV data. [1]

[1] line 23594, /usr/share/info/emacs-24/gnus.info.gz

-- 
underground experts united
http://user.it.uu.se/~embe8573