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

[Richard Stallman]

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

In Emacs, GC doesn't occur when memory is scarce; Emacs doesn't
measure that.  GC occurs based on the amount of consing done.  If the
markers are not freed, Emacs will allocate more space for markers.

    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.

That is also a factor, indeed.

    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 would be the basic RESEAT functionality in `set-match-data'.
Perhaps it is the right thing to do, but I still wonder how much
extra space the extra GCs will cause.

It occurs to me that free_marker could un-count the consing of that
marker, so that GC would also happen less often.