Re: #2 Org mode profiling meetup on Sat, Mar 26 (was: Org mode profiling meetup on Sat, Feb 26 (was: profiling latency in large org-mode buffers (under both main & org-fold feature)))

[Ihor Radchenko]

Ihor Radchenko <yantar92@gmail.com> writes:

>> The time will be the same: 9pm SG time (4pm Moscow; 8am New York; 1pm
>> London). Sat, Mar 26
>>
>> I will post the link to the meeting one hour before the meeting start.
>
> Here is the link https://teamjoin.de/Org-dev-profiling-20220326-d708k

The recording is available at
https://open.tube/videos/watch/4d819114-43bf-42df-af94-f94fc53dd0d9

Summary of the talk:

Table of Contents
─────────────────

1. Testing bugs in clean environment and latest Org
.. 1. Org manual!
.. 2. Alternative demo
.. 3. What to report
2. Testing bugs in personal config (bisecting config)
3. Using Emacs profiler and sharing profiler results
.. 1. The basic idea
.. 2. Profile buffer
.. 3. Caveats                                                   :ATTACH:


1 Testing bugs in clean environment and latest Org
══════════════════════════════════════════════════

1.1 Org manual!
───────────────

  <https://orgmode.org/> -> Contribute -> Feedback (yes, it is a bit
  obscure) -> <https://orgmode.org/org.html#Feedback>


1.2 Alternative demo
────────────────────

  • Fetch the latest Org <https://orgmode.org>
    ┌────
    │      cd /tmp/ # on Linux, can be any other dir.
    │      git clone git://git.sv.gnu.org/emacs/org-mode.git # You need git to 
be installed. 
    └────
    Alternative: <https://elpa.gnu.org/packages/org.html> (only latest
    stable version aka bugfix branch)
  • Create minimal working environment
    ┌────
    │      cd org-mode
    │      git checkout main 
    │      # or
    │      # git checkout bugfix
    │      make cleanall # useful if you re-use the already downloaded dir
    │      make autoloads # auto-generate some files for Emacs
    └────
  • Run clean Emacs
    ┌────
    │      emacs -Q -L ./lisp -l org
    │      # or to open a clean org buffer
    │      # emacs -Q -L ./lisp -l org /tmp/test.org
    │      # or use a minimal configuration saved in /tmp/test.el, if required
    │      emacs -Q -L ./lisp -l org -l /tmp/test.el /tmp/test.org
    └────
  • Enable extra debugging Put the following into test.el
    ┌────
    │      ;; Activate generic debugging.
    │      (setq debug-on-error t
    │            debug-on-signal nil
    │            debug-on-quit nil)
    │      ;; Activate org-element debugging.
    │      (setq org-element--cache-self-verify 'backtrace
    │            org-element--cache-self-verify-frequency 1.0 ; can be less if 
there are lags.
    │            org-element--cache-map-statistics t)
    └────


1.3 What to report
──────────────────

  There is some common information we find extremely useful when
  diagnosing bug reports.

  • The easiest is using M-x `org-submit-bug-report'
    • Most of common require info will be auto-inserted into email
    • You don't have to configure Emacs for sending email. Can simply
      use `org-submit-bug-report' and copy-paste the text into email
      client of choice.
  • If there are warnings, can also share what is inside `*Warnings*'
    buffer: M-: `(switch-to-buffer "*Warnings*")'
  • Same for `*Messages*' M-: `(switch-to-buffer "*Messages*")'
  • Screenshots are often helpful


2 Testing bugs in personal config (bisecting config)
════════════════════════════════════════════════════

  <https://github.com/Malabarba/elisp-bug-hunter>

  • M-x `bug-hunter-init-file'
  • Usually works out of the box, but may not give useful results when
    `init.el' is a single sexp block
    ┌────
    │   (let ((org-file '"/home/yantar92/Git/emacs-config/config.org")
    │       (el-file '"~/.emacs.d/config.el"))
    │       (setq init-flag t)
    │       (setq comp-deferred-compilation-deny-list '("pdf-cache" 
"org-protocol"))
    │       (load el-file))
    └────
    • Then, need to dump the actual config into `init.el'
  • Sometimes, a bug in personal config is caused by interaction between
    two packages
    ┌────
    │   (require 'package1)
    │   ;; some setting causing package1 to break, but only when package2 below 
is loaded
    │   (require 'package2)
    └────
    • `bug-hunter' will then point to `(require 'package2)' as the
      problematic line, instead of the actual setting
    • It can help then to reshuffle the config, so that `package1' and
      `package2' are loaded early:
      ┌────
      │     (require 'package1)
      │     (require 'package2)
      │     ;; some setting causing package1 to break, but only when package2 
below is loaded
      └────


3 Using Emacs profiler and sharing profiler results
═══════════════════════════════════════════════════

3.1 The basic idea
──────────────────

  1. M-x `profiler-stop' *Important*: if a profiler is already running,
     the report will contain irrelevant data
     • `profiler-stop' may not be available right after Emacs start. If
       it is not listed in M-x completions, no need to run it
  2. M-x `profiler-start' <RET> `cpu' <RET>
  3. Do slow staff you want to test
  4. M-x `profiler-report'
  5. M-x `profiler-report-write-profile'
  6. Attach the report file to you bug report
  7. (FYI) M-x `profiler-find-profile' can be used to view the saved
     report later


3.2 Profile buffer
──────────────────

  • You can <TAB> to fold/unfold entries
  • … can reveal useful info!
  • so does `redisplay_internal (C function)'
  • Useful staff reveals itself as "%" value changes noticeable deeper
    into the nested tree

3.3 Caveats
───────────

  • If your Emacs hangs for a long time while recording a profile and
    you abort with `C-g', profiler will likely contain garbage data
  • Calling M-x `profiler-report' twice in a row will not give anything
    useful The second call will profile actions done between the first
    and second calls.
  • Profiler does not show how frequently a function is called
    • Information on number of calls can be obtained using other kind of
      profiler: `ELP'
      ┌────
      │     (require 'elp)
      │     (elp-restore-all) ;; Cleanup
      │     (elp-instrument-function #'org-element-cache-map) ; or any other 
function
      │     ;; Do slow staff.
      │     (elp-results)
      └────
  • Byte-compilation and native-compilation can sometimes create cryptic
    profiles
    • It helps to go to function definition manually and re-evaluate it
      1. M-x `describe-function' <RET> `function-name' <RET>
      2. Go to the definition "… is an interactive native compiled Lisp
         function in ‘some-file-click-on-it.el’."
      3. C-M-x (or M-x `eval-defun')
      4. Redo the profiling

Best,
Ihor