>> 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 <m...@nicolasgoaziou.fr> writes:
> Hello,
>
> Ihor Radchenko <yanta...@gmail.com> 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: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
