Re: Trying to enter a group: "registry max-hard size limit reached"

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 10 May 2011 12:29:03 +0200 asjo@koldfront.dk (Adam Sjøgren) wrote: 

AS> On Mon, 09 May 2011 12:55:00 -0500, Ted wrote:
AS> I am pretty sure that I set gnus-registry-max-entries because the
AS> registry file got very large and it took a while to load, but I have
AS> never experienced problems with this setting before.

>> The load+save is much faster now that it's entirely managed by EIEIO
>> with a native hashtable, but certainly if you want to save memory and
>> speed Gnus up, it's better to turn the Gnus registry off.

AS> The speed-up is great, but if it makes Gnus stop working when the
AS> registry reaches the size limit, all the speed in the world ain't worth
AS> so much...

I think I've fixed it with the last commits so the pruning will DTRT to
the hard and soft limits.  There is no sort function in gnus-registry
yet so semi-random entries will be removed, but I'll add that too when I
get a chance.

On Tue, 10 May 2011 12:29:15 +0200 asjo@koldfront.dk (Adam Sjøgren) wrote: 

AS> On Mon, 09 May 2011 12:52:02 -0500, Ted wrote:

>> Now the code calls `registry-prune' but will still fail if the registry
>> is full.  I think that's the right thing to do, though I could ask the
>> user if he wants to increase `gnus-registry-max-entries'.

AS> So how does it compare to before the registry rewrite? The way it was
AS> handled then Just Worked(tm) for me for years, even with the small value
AS> I had set...

We're back to that situation now.  But it will always take up memory and
slows down article copy/move/spool operations.  So if you need registry
article marks, spam tracking through the registry (a feature I don't
think anyone needs), or splitting articles to the parent reference's
group, use it, but otherwise don't bother.

Ted