bug#122: 23.0.60; Slowdown in directory scanning over time.

[Kenichi Handa <handa@m17n.org>]

In article <E1KdpeJ-0004Sb-Oj@fencepost.gnu.org>, "Richard M. Stallman" <rms@gnu.org> writes:

> There must be a bug in the logic that decides whether to make a new
> code-conversion buffer, so that it makes too many of them.

> The code looks inefficient too.  Even when it reuses the
> code-conversion buffer, it calls Fget_buffer_create.
> It seems to be killing and recreating these buffers,
> which must be slow.

???  I don't see what's wrong with the current code.  I
think the functions make_conversion_work_buffer,
code_conversion_save, and code_conversion_restore do the
right thing.

> I think it would be better to make one and never kill it.

> Handa-san, under what circumstances should it need to use more than
> one of these buffers?  Can character set encoding and decoding ever be
> done recursively?  It seems to me that that should never happen, so
> one such buffer should be enough.

There are two cases that multiple work buffers are necessary.

(1) A coding system can have pre-write-conversion function,
and that function can call code-conversion function
recursively.

(2) If REPLACE arg is non-nil in insert-file-contents and a
file need a decoding, we call decode_coding_c_string while a
work buffer is in use.

Anyway, I fixed one bug in insert-file-contents.  It failed
to run code_conversion_restore in one situation.  So, could
you try again with the latest code?

---
Kenichi Handa
handa@ni.aist.go.jp