Ihor Radchenko <yanta...@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
