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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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.

Someone needs to write the "optimized" but correct version first.

> 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.

No: the current code (where I removed the `evaporate' optimization)
still unseats the markers right away.  It just doesn't free them.

> 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.

That's already what the `unseat' argument does (which used to accept
a special `evaporate' value to imply that it shouldn't just unseat but
also free).


        Stefan