[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Monnier
Subject: Re: mark_object crash in 22.1 and latest CVS (as of tonight)
Date: Mon, 19 Nov 2007 02:50:10 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]