Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Nicolas Goaziou]

Hello,

Ihor Radchenko <address@hidden> writes:

> To my surprise, the patch did not break org to unusable state and
> the performance on the sample org file [3] improved drastically. You can
> try by yourself!

It is not a surprise, really. Text properties are much faster than
overlays, and very close to them features-wise. They are a bit more
complex to handle, however.

> However, this did introduce some visual glitches with drawer display.
> Though drawers can still be folded/unfolded with <tab>, they are not
> folded on org-mode startup for some reason (can be fixed by running
> (org-cycle-hide-drawers 'all)). Also, some drawers (or parts of drawers)
> are unfolded for no apparent reason sometimes. A blind guess is that it
> is something to do with lack of 'isearch-open-invisible, which I am not
> sure how to set via text properties.

You cannot. You may however mimic it with `cursor-sensor-functions' text
property. These assume Cursor Sensor minor mode is active, tho.
I haven't tested it, but I assume it would slow down text properties
a bit, too, but hopefully not as much as overlays.

Note there are clear advantages using text properties. For example, when
you move contents around, text properties are preserved. So there's no
more need for the `org-cycle-hide-drawer' dance, i.e., it is not
necessary anymore to re-hide drawers.

> Any thoughts about the use of text properties or about the patch
> suggestion are welcome.  

Missing `isearch-open-invisible' is a deal breaker, IMO. It may be worth
experimenting with `cursor-sensor-functions'.

We could also use text properties for property drawers, and overlays for
regular ones. This might give us a reasonable speed-up with an
acceptable feature trade-off.

Anyway, the real fix should come from Emacs itself. There are ways to
make overlays faster. These ways have already been discussed on the
Emacs devel mailing list, but no one implemented them. It is a bit sad
that we have to find workarounds for that.

Regards,

-- 
Nicolas Goaziou