emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: profiling latency in large org-mode buffers (under both main & org-f


From: Samuel Wales
Subject: Re: profiling latency in large org-mode buffers (under both main & org-fold feature)
Date: Mon, 21 Feb 2022 15:22:41 -0700

i have been dealing with latency also, often in undo-tree.  this might
be a dumb suggestion, but is it related to org file size?  my files
have not really grown /that/ much but maybe you could bisect one.  as
opposed to config.

i am not saying that your org files are too big.  just that maybe it
could lead to insights.


On 2/21/22, Matt Price <moptop99@gmail.com> wrote:
> I'm trying to figure out what causes high latency while typing in large
> org-mode files.  The issue is very clearly a result of my large config
> file, but I'm not sure how to track it down with any precision.
>
> My main literate config file is ~/.emacs.d/emacs-init.org, currently 15000
> lines, 260 src blocks.
> If I create a ~minimal.el~ config like this:
>
> (let* ((all-paths
>           '("/home/matt/src/org-mode/emacs/site-lisp/org")))
>     (dolist (p all-paths)
>       (add-to-list 'load-path p)))
>
>   (require 'org)
>   (find-file "~/.emacs.d/emacs-init.org")
>
> then I do not notice any latency while typing.  If I run the profiler while
> using the minimal config, the profile looks about like this at a high
> level:
>
>         1397  71% - command-execute
>          740  37%  - funcall-interactively
>          718  36%   - org-self-insert-command
>          686  34%    + org-element--cache-after-change
>           10   0%    + org-fold-core--fix-folded-region
>            3   0%    + blink-paren-post-self-insert-function
>            2   0%    + jit-lock-after-change
>            1   0%
> org-fold-check-before-invisible-edit--text-properties
>            9   0%   + previous-line
>            6   0%   + minibuffer-complete
>            3   0%   + org-return
>            3   0%   + execute-extended-command
>          657  33%  - byte-code
>          657  33%   - read-extended-command
>           64   3%    - completing-read-default
>           14   0%     + redisplay_internal (C function)
>            1   0%     + timer-event-handler
>          371  18% - redisplay_internal (C function)
>          251  12%  + jit-lock-function
>           90   4%  + assq
>            7   0%  + substitute-command-keys
>            3   0%  + eval
>          125   6% + timer-event-handler
>           69   3% + ...
>
> --------------------------
> However, if I instead use my fairly extensive main config, latency is high
> enough that there's a noticeable delay while typing ordinary words. I see
> this  regardless of whether I build from main or from Ihor's org-fold
> feature branch on github. The profiler overview here is pretty different --
> redisplay_internal takes a much higher percentage of the CPU requirement:
>
>          3170  56% - redisplay_internal (C function)
>          693  12%  - substitute-command-keys
>          417   7%   + #<compiled -0x1c8b98a4b03336f3>
>           59   1%  + assq
>           49   0%  + org-in-subtree-not-table-p
>           36   0%  + tab-bar-make-keymap
>           35   0%    and
>           24   0%  + not
>           16   0%    org-at-table-p
>           13   0%  + jit-lock-function
>            8   0%    keymap-canonicalize
>            7   0%  + #<compiled 0x74a551771c7fdf1>
>            4   0%  + funcall
>            4   0%    display-graphic-p
>            3   0%  + #<compiled 0xe5940664f7881ee>
>            3   0%    file-readable-p
>            3   0%  + table--probe-cell
>            3   0%    table--row-column-insertion-point-p
>         1486  26% - command-execute
>         1200  21%  - byte-code
>         1200  21%   - read-extended-command
>         1200  21%    - completing-read-default
>         1200  21%     - apply
>         1200  21%      - vertico--advice
>          475   8%       + #<subr completing-read-default>
>
> ----------------------
> I've almost never used the profiler and am not quite sure how I should
> proceed to debug this.  I realize I can comment out parts of the config one
> at a time, but that is not so easy for me to do in my current setup, and I
> suppose there are likely to be multiple contributing causes, which I may
> not really notice except in the aggregate.
>
> If anyone has suggestions, I would love to hear them!
>
> Thanks,
>
> Matt
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]