On 23/02/2022 23:35, Ihor Radchenko wrote:
Max Nikulin writes:
+;; the same purpose.  Overlays are implemented with O(n) complexity in
+;; Emacs (as for 2021-03-11).  It means that any attempt to move
+;; through hidden text in a file with many invisible overlays will
+;; require time scaling with the number of folded regions (the problem
+;; Overlays note of the manual warns about).  For curious, historical
+;; reasons why overlays are not efficient can be found in
+;; https://www.jwz.org/doc/lemacs.html.
The linked document consists of a lot of messages. Could you, please,
provide more specific location within the rather long page?
There is no specific location. That thread is an old drama unfolded when
intervals were first implemented by a third-party company (they were called
intervals that time). AFAIU, the fact that intervals are stored in a
list and suffer from O(N) complexity originates from that time. Just
history, as I pointed in the comment.
Thank you, Ihor. I am still not motivated enough to read whole page but 
searching for "interval" (earlier I tried "overlay") resulted in the 
following message:
Message-ID:             <9206230917.aa16...@mole.gnu.ai.mit.edu>
Date:   Tue, 23 Jun 92 05:17:33 -0400
From:   r...@gnu.ai.mit.edu (Richard Stallman)

describing tree balancing problem in GNU Emacs and linear search in lucid.

Unfortunately there is no "id" or "name" anchors in the file suitable to specify precise location. Even the link href is broken.
Actually I suspect that markers may have a similar problem during regexp 
searches. I am curious if it is possible to invoke a kind of "vacuum" 
(in SQL parlance). Folding all headings and resetting refile cache does 
not restore performance to the initial state at session startup. Maybe 
it is effect of incremental searches.
Sorry, I have not tried patches for text properties instead of overlays.


Reply via email to