Re: `make-overlay' very slow

[Stefan Monnier]

>> Yes, that would be great.  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.

> I have not yet thought about this idea in deep but perhaps
> we can use one more interval tree for overlays.

Yes, to speed up overlays algorithmically, we'd want to implement
them with some kind of tree.  If we could share some of the code with
the text properties's interval tree that would be great, indeed.

> More radical idea, not related to overlays, is to make one
> interval tree for one text property; i.e. one for `face',
> one for `fontified'...  I think it not only improves the
> processing speed, but also reduces the memory usage
> (next-property-change will get slower, but we use
> next-single-property-change more often).

I've been tempted as well, but I'm not sure it'd be much of
an improvement.  You'd end up with many trees, so might need
a hash-table or some other tree to map text-property names to the
corresponding interval tree.


        Stefan