On 11/02/2021 23:59, Ihor Radchenko wrote:
Maxim Nikulin writes:
It is not namely typing latency, but I have noticed lags while moving
over collapsed headings with "up" key (with "down" it is not so
apparent) e.g. in overview view. It has happened after linux upgrade,
emacs version changed from 25.2 to 25.3, system package with org mode
updated as well. The org file has significant size: 50k lines, 2Mb. I
have created a LXC container to compare performance with older emacs. It
is quite strange. With org version from git, emacs version is not really
important, flyspell mode is irrelevant.
You can try feature/org-fold branch aiming to address issues with
performance on large files https://github.com/yantar92/org
Ihor, I have seen the thread with discussion of your branch. This case I
was surprised the simple move to next or previous currently displayed
line could be slow. I would expect that emacs has information (in some
internal structures) what position in the buffer is related to the same
x coordinate on the previous or next (visual) visible line. Ideally it
would not depend on how much text is hidden by overlays, properties,
etc. and should work instantly.
Update to my results. I suspected some problem with loader and I have
realized what actually had happened. I believed that -L (--directory)
emacs command line options have precedence and used the following command
emacs -L ~/org-mode/lisp test-file.org
actually -L processed after init.el file, so (require 'org-protocol) in
the init file loaded some files from org-9.1.6 (elpa-org system package)
then remaining files were loaded from git HEAD org version. Even
org-submit-bug-report did not worked, I tried it to get summary of
actual configuration. I do not run emacs in such way routinely, so the
problem was specific to my tests.
My current impression that in both cases of emacs-25.2 and 26.3, with
org from git moving cursor over collapsed headers works faster than with
org-9.1.6 or org-9.3.1 from elpa-org package. In all cases
line-move-visual dominates in profiler reports.
So slow down I have noticed is likely related to growth of the file size
rather than to system upgrade. I just mostly navigate through the file
using C-u C-c C-j, so I just was not using cursor keys in overview tree
display for some time.
So strange observation, due to that I sent previous message, is
explained: incorrect usage of command line option during tests. My
complains related to performance is not related to emacs upgrade, org
master branch HEAD from git works better. Maybe later I will try
suggestions how to improve performance or I will just split my file into
smaller parts.
Sorry for the noise.