Re: New buffer-case-table makes search_buffer painfully slow

[Elias Oltmanns]

Elias Oltmanns <address@hidden> wrote:
> Hi all,
>
> switching from emacs 21 to emacs 22 has a very significant performance
> impact on packages that make heavy use of search_buffer. An example
> that actually made me aware of this problem is gnus processing large
> mbox files. Further analysis of this problem revealed that in emacs 22
> an "i" in the search string makes search_buffer use simple_search()
> instead of boyer_moore(). 

Emacs 22's EQUIVALENCES table relates i, and thus I as well, to two
more characters with character codes 331857 and 331856. On
www.unicode.org the character look up engine couldn't find a match for
U+51051 or U+51050 saying that most likely those codes weren't
assigned to any characters yet.

So, here is a plain question: Is there a bug in the case-table in
emacs 22 or does the search engine on www.unicode.org for some reason
miss certain character ranges? Slightly biassed, I'm disregarding the
possibility of me being unable to use www.unicode.org properly, which,
in fact, might well be the reason for my confusion.

Second question: If the case-table was right, what would be the right
way to tacle the problem described in my original post? For me the
following snippet in .emacs solves the problem:
--- ~/.emacs ---
(unless (< emacs-major-version 22)
  (set-case-syntax 331856 "w" (standard-case-table))
  (set-case-syntax 331857 "w" (standard-case-table)))
--- ~/.emacs ---

This, of course, is a durty hack and I'm wondering whether emacs
should provide a feature to "clean up" the EQUIVALENCES table in the
ascii range in order to avoid falling back to a slow search
algorithm when we are searching for pure ascii strings. Or do you
think that packages like gnus which make heavy use of
re-search-forward should handle these performance issues
themselves---or indeed the users.

Regards,

Elias