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

[Ihor Radchenko]

>> I tested with master + my personal config + native compilation of org,
>> Emacs native-comp branch, commit c984a53b4e198e31d11d7bc493dc9a686c77edae.
>> Did not see much improvement.
>> Vertical motion in the folded buffer is still quite slow.
>
> Oh! This is embarrassing. I improved speed, then broke it again in
> a later commit. Sorry for wasting your time. I think I fixed it again.
> Thank you for the feedback.
>
> Could you have a look again?

I still do not feel much difference, so I used elp to quantify if there
is any difference I cannot notice by myself. I tested the time to move
from to bottom of the example file with next-logical-line.

org master (7801e9236):
6(#calls)           2.852953989(total time, sec)   0.4754923315(average)
      
org e39365e32:
6           2.991771891   0.4986286485

org feature/drawertextprop:
6           0.149731379   0.0249552298

There is small improvement in speed, but it is not obvious.

> ... In current master,
> it means there is at most 5217 overlays in the buffer. With text
> properties, the worse situation in the same.

Do you mean that number of overlays is same with text properties? I feel
that I misunderstand what you want to say. 

> Of course, that case happens less often with text properties. For
> example, it happens in "contents" view in both cases. However, in "show
> all" view, it is only a problem with overlays.

I am completely lost. What do you mean by "that case"?

Best,
Ihor

Nicolas Goaziou <address@hidden> writes:

> Hello,
>
> Ihor Radchenko <address@hidden> writes:
>
>>> Oops, you are right. I fixed this. It should be way faster. I can
>>> navigate in your example file without much trouble.
>>>
>>> Please let me know how it goes.
>>
>> I tested with master + my personal config + native compilation of org,
>> Emacs native-comp branch, commit c984a53b4e198e31d11d7bc493dc9a686c77edae.
>> Did not see much improvement.
>> Vertical motion in the folded buffer is still quite slow.
>
> Oh! This is embarrassing. I improved speed, then broke it again in
> a later commit. Sorry for wasting your time. I think I fixed it again.
> Thank you for the feedback.
>
> Could you have a look again?
>
>> Apparently I misunderstood the purpose of: 1027e0256
>> "Implement `org-cycle-hide-property-drawers'"
>
> The function is meant to re-hide only property drawers after visibility
> cycling. Its purpose is not to improve /unfolding/ speed. Unfolding is
> very fast already, faster than using text properties.
>
> Folding has roughly the same speed in both cases: most time is spent
> looking for the next location to fold. However, folding with text
> properties is more resilient, so you fold less often.
>
> As a side note, your file contains 5217 headlines and 5215 property
> drawers. I'll ignore the 3989 regular drawers for the time being
> (although they do contribute to the slow navigation). In current master,
> it means there is at most 5217 overlays in the buffer. With text
> properties, the worse situation in the same.
>
> Of course, that case happens less often with text properties. For
> example, it happens in "contents" view in both cases. However, in "show
> all" view, it is only a problem with overlays.
>
> Regards,
>
> -- 
> Nicolas Goaziou

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: address@hidden, address@hidden