[Top][All Lists]

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

Re: [Emacs-diffs] trunk r114117: * buffer.c (drop_overlay):

From: Dmitry Antipov
Subject: Re: [Emacs-diffs] trunk r114117: * buffer.c (drop_overlay):
Date: Sat, 07 Sep 2013 08:37:14 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

[This is from private e-mail to Stefan due to:
 <address@hidden>: connect to
 pinpin.IRO.UMontreal.CA[]:25: Connection timed out]

On 09/03/2013 11:25 PM, Stefan Monnier wrote:

Thinking about optimizing markers.
How 'bout changing unchain_markers so it is constant time: add a new
"unchained" bit in the Lisp_Marker struct and set it to true there.
Then reap those markers that are "unchained but still in the list"
lazily, either during GC or when we traverse the list for some
other reason, or when we really have to because the marker is being
re-chained elsewhere (but not if it's being rechained in the same

This looks good, and I'll try to implement this.

I'm also thinking about offloading GC with explicit marker freeing.
For example, save-excursion creates up to 2 markers each time, and
this is the well-known bottleneck because there may be thousands
calls to save-excursion per just one basic editing command in cc-mode.
But we can't use free_marker instead of unchain_marker
in save_excursion_restore because the marker may be recorded in
buffer undo list, and freeing it creates dangling pointer (I hit
this problem in r109221, and the latter was immediately reverted :-().
So I suppose that we need one more bit for internal temporary
markers that are invisible to Lisp and presumably have short lifetime -
such a markers should not be included in undo lists and so can be
safely freed when they're not needed anymore.


reply via email to

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