Re: ifile sloooow... hook for expiry?

Re: ifile sloooow... hook for expiry?

[Ted Zlatanov]

On Mon, 13 Jan 2003, dmaze@mit.edu wrote:
> I've had that experience too; ifile-gnus seems to be a little
> aggressive about noticing refiles, particularly in spam mode, and
> I've noticed general slowness.  Rumor is that ifile is a lot slower
> if your .idata file is on a networked filesystem (e.g. NFS or AFS),
> and that it gets noticably faster if you move it to local disk.
> 
> Hmm.  ifile-gnus uses lots of advice stuff; Oort Gnus (the current
> development version) has somewhat bleeding support for ifile via a
> generic spam-filtering system in spam.el.  You can get a day-old
> tarball fromm http://www.gnus.org/dist/.  But you should be aware
> that it really is bleeding-edge code, might not work, might eat all
> your mail, etc.

Agreed on the bleeding-edginess (I maintain spam.el).  Its support to
ifile is also limited to spam detection and processing currently - it
does not do general mail sorting when articles are moved or copied,
even though it *does* have support for general sorting of incoming
mail through ifile.  If you or others like spam.el and want to see it
integrated better with ifile, let me know.

With spam.el all the advice is turned off, and only specified articles
will be processed by ifile at summary exit (the rules are somewhat
complex, and explained in the CVS Gnus manual).  spam.el should be
faster than regular ifile-gnus.el with article copy/move.

Also, spam.el lets you customize the location of your .ifile database.

> *thinks* ...I've noticed spam.el being slow when you exit a group,
> though, because it deals with telling ifile an article definitly is
> or isn't spam then;

I've been considering speeding that up.  The current version is slow
but it can be optimized quite a bit for nnml groups.  It is much
easier, however, to add new spam backends and to improve the
functionality with the current code architecture, so I've been leaving
speed optimizations off.

Ted