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

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

[Dmitry Antipov]

[This is from private e-mail to Stefan due to:
  <monnier@IRO.UMontreal.CA>: connect to
  pinpin.IRO.UMontreal.CA[132.204.24.52]: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
> buffer).

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.

Dmitry

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

[Stefan Monnier]

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

I'm not sure it would be worth the trouble.  Maybe a more promising
direction would be to avoid using markers in save-excursion.

In my experience, most save-excursions are used around code which makes
no buffer modifications, in which case plain integers would work just
as well.

So it might be beneficial for save-excursion to be optimistic and use
integers (with some appropriate hooking into maybe
prepare_to_modify_buffer to turn them into markers when needed).

But even there, I'm not sure it would really speed up cc-mode noticeably.


        Stefan