bug#3603: 23.0.94; takes much time to save large non-ASCII buffers

[Kenichi Handa <handa@m17n.org>]

In article <wleithrioa.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Steps to reproduce:
>   1. emacs -Q
>   2. C-x ( C-x i .../etc/tutorials/TUTORIAL.ja RET C-x )
>   3. C-u 20 C-x e
>   4. C-x C-s SOME-NEW-FILE-NAME RET

> Result:

>   It takes much time (~10 sec.) to save this ~1MB buffer.
>   Emacs 22 can save it instantly.

I observed it too.

> The slowness comes from that of select-safe-coding-system, in
> particular, find-coding-systems-region(-internal) in it.  The
> following patch makes it much faster (a few sec.) than the current
> version.

It seems that your patch is correct.  Actually, Emacs 22
used the similar method, but I forgot to implement that part
when I re-wrote find-coding-systems-region-internal.  :-(

[...]
>   1. It's still much slower than Emacs 22.  I guess we need to rewrite
>      select-safe-coding-system if we try to make its performance
>      comparable with Emacs 22.  But perhaps we should avoid such
>      changes at this moment.

One possible strategy is to check, at first, whether or not
the default coding system(s) used for encoding (usually
buffer-file-coding-system) can encode the text.

>   2. If the "if (charset_map_loaded) ..." clause in
>      Ffind_coding_systems_region_internal is intended for the
>      relocation caused by GC, then maybe `chars_checked' above (and
>      also `coding_attrs_list') should be GCPROed.

It was.  But, as we modified load_charset_map_from_file to
disable file-name-handlers a while ago, we don't need that
check anymore.  I just forgot to delete all those checks.

---
Kenichi Handa
handa@m17n.org