Re: mark_object crash in 22.1 and latest CVS (as of tonight)

[David Kastrup]

Richard Stallman <address@hidden> writes:

>     It's an "optimization" and nothing more.  In my book, if an
>     optimization is unsafe, it had better make a good case for itself.
>     As it stands I see no evidence that this optimization is ever
>     useful.  As long as nobody can show us numbers that demonstrate a
>     measurable performance impact, I think we're better off without
>     this optimization.
>
> Yes, that's the crucial question.  It should be easy to get some
> numbers by running an interactive application that often uses
> save-match-data and compare the memory usage and amount of GC of the
> two versions.

The problem is not the memory usage: garbage collection will set in
anyway when the memory is tight.

The problem is that editing becomes awfully slow in a buffer with many
markers.  And temporary markers created with save-match-data will only
be unseated from the buffer once they get collected.

Perhaps it would be a useful idea to have the "evaporate" argument only
unseat the markers from the buffer (the equivalent of (move-marker
marker nil)) without garbage-collecting it.

I think that should meet the main performance objective without
introducing any spurious "free" potential.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum