Re: Fwd: Serious performace problems on Windows XP with new(!) GNU Emacs v22 (both patched and unpatched EmacsW32 were tried)

[martin rudalics]

> If you've found a slowness in remove-overlays, could you aim to make
> that function faster, rather than making its caller faster by not using
> remove-overlays?

Using `remove-overlays' to delete all overlays with a given property is
overkill.  The tests

        (if (< (overlay-start o) beg)
            (if (> (overlay-end o) end)
               ...
          (if (> (overlay-end o) end)

are needed iff you want to split or move overlays.  Admittedly, my
change doesn't gain too much, hence there's no need to implement it.

On the other hand, doing "(overlay-recenter (point-max))" before
deleting the overlays seems crucial.  Apparently, `overlays-in' always
returns a list of overlays in reverse order of their buffer positions.
With the overlay center at bob, unchain_overlay always searches till the
end of overlays_after, hence overhead is inherently quadratic with
respect to the number of overlays in the buffer.

With the overlay center at eob unchain_overlay always stops at the first
element of overlays_before.  Thus, an improvement of `remove-overlays'
would start it with "(overlay-recenter end)" (possibly directed by an
optional fifth argument).

Maybe what's really needed is a C function, say "delete_overlays_in",
that deletes all overlays with a given property in a given region.  The
overhead would be always linear with respect to the number of overlays
in the buffer.