Re: RMAIL slows

[Stefan Monnier]

> OK, I am back.  [Problem: over time, a batch deletion of 50 or 100
> RMAIL files takes longer and longer.  This slow down only happens
> after an instance of Emacs has been running for several days.  New
> instances are quick.  Unfortunately, Emacs looks fine to me.]

> Using GDB, the bug seems to be in

>     re_match_2_internal 

OK, here is some info that might help you get info that's more useful:

There are several possible cases:
- some code calls re_match_2_internal more often over time.
  I.e. the calls to re_match_2_internal do not get slower themselves,
  so the problem is elsewhere.

- the calls to re_match_2_internal get slower for some reason.
  This may be because:
  - the regexp changes over time.
  - the text matched changes over time.
  - some side-data makes the code slower over time.

Now, re_match_2_internal is a function that can easily take an insane amount
of time to terminate (its complexity is exponential), depending mostly on
the regexp used.  It's a misfeature, but we do not usually consider it as
a bug, and instead we try to avoid pathological cases.

So a good thing to do is to look at the regexp that's being matched
(typically: look up the backtrace to see the value of the `string' argument
to search_buffer, then do "print string" and then "xstring" to see the
actual string).  If you don't know how to recognize regexps that can lead to
pathological exponential behavior, post it here.
Another good thing to do is to look at the text being matched (look at some
of the char* variables).

Another good thing to do is to say "finish" to let the code run until the
end of re_match_2_internal.  If it's immediate it means the problem is maybe
not in the time taken in each call to re_match_2_internal, but rather in the
number of calls.


        Stefan