--- Begin Message ---
|
Subject: |
wishlist: improve speed of `make-overlay' |
|
Date: |
Sat, 11 Apr 2009 16:02:50 +0200 (CEST) |
The complexity of `make-overlay' appears to be O(N), which makes it
unbearably slow for larger buffers. In my test case, it started with
about 1000 calls per second, and after about 10000 calls it already
reduced to approx. 100 calls per second.
On the other hand, handling text properties is O(log N), which works
fine even for my 400000 line document.
Stefan says:
But note that it's not just `make-overlay': every time we make a
modification to the buffer, we have to update the position of all
the overlays (and markers) after point. So, yes, a better
data-structure for overlays (and markers) would be very welcome.
Werner
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#2963: wishlist: improve speed of `make-overlay' |
|
Date: |
Sat, 21 Oct 2023 04:52:15 -0700 |
Eli Zaretskii <eliz@gnu.org> writes:
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>, wl@gnu.org,
>> Stefan Monnier <monnier@iro.umontreal.ca>, politza@hochschule-trier.de
>> Date: Sat, 21 Oct 2023 08:33:34 -0300
>> From: Mauro Aranda <maurooaranda@gmail.com>
>>
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>> > Werner LEMBERG <wl@gnu.org> writes:
>> >
>> >> The complexity of `make-overlay' appears to be O(N), which makes it
>> >> unbearably slow for larger buffers.
>> >
>> > Andreas did a lot of work on reimplementing the overlay internals a few
>> > years back -- but I see that it was never merged?
>> >
>> > Andreas, what's the state of the feature/noverlay branch?
>>
>> This message was 2 years ago. Meanwhile the feature/noverlay branch got
>> merged. Maybe this can be closed. CCing Stefan M.
>
> I think it should be closed, indeed.
Yup, done.
--- End Message ---