Re: [RFC]: replace-region-contents

[Tassilo Horn <tsdh@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Paul,

the context is `replace-buffer-contents' or rather compareseq in
lib/diffseq.h being too slow when being called where the source buffer
contains a huge, one-line JSON string and the replacing buffer contains
the formatted version.  I.e., the buffer contents are almost equal
modulo gazillion of whitespace/linebreak changes.

>> Maybe that could signal if more than some maximum number of
>> differences have already been found, and in that case
>> `replace-buffer-contents' would fallback to a plain delete and
>> insert?
>
> There's the too_expensive member that we currently set to a very large
> value; maybe we should set it lower? or provide control on it from
> Lisp?

I've just tried playing with that.  We currently set it too one million,
and then the `replace-buffer-contents' call won't finish within 30
minutes on my computer.  As a base-line, the current `json-pretty-print'
without `replace-buffer-contents' takes about 2 seconds.

With a too_expensive value of 1000, it takes about 14 seconds with my
huge, worst-case JSON file.  With a value of 100 it takes about 3
seconds.  With a value of 10, it segfaults.  I guess there's some
minimum boundary.

However, I'm not really sure what the implications are.  The comments
say it produces suboptimal output.  But what does that mean here?  In
the end, the formatted JSON is copied over from the replacing buffer
as-is, and that's the most important thing.

> Also, there's the EARLY_ABORT macro that can be defined to cause an
> early return when the job is too hard.  Maybe you could try defining
> it to something appropriate?

And fallback to plain delete & insert when it returned early?  Not sure
if that's better.  Right now, a (much) lower value of too_expensive
seems like a good option.

Bye,
Tassilo