I often end up with 8-10 org-roam windows open, often spread across two frames. Entering text into an org-roam note can take seconds to appear. I’ve been noticing more green block cursors while I wait for key-strokes to happen in the UI. Often this starts out okay but gets worse over a few hours.
I don’t know that this is an org-roam issue specifically. That’s the main reason I’ve held off asking this question as I’m sure where to look for help. However, this has concerned me for months.
Most of the files I’m working with are small, 1-2 KB. A few are in the 50 KB region. My zettelkasten currently contains just under 500 files. All of these files are associated with org-agenda for refiling purposes. I do a lot of searches using Helm Ag, and since moving from 26.3 to 27 the responsiveness of Helm itself has been greatly improved.
I’m using Emacs 27.1 with Spacemacs develop branch and org-roam, all up to date. I understand that there are limitations to emacs and multi-threading but I’ve got plenty of power here. 3.5GHz 6 core hyper-threading with 64GB of RAM. (I wish Emacs would make more use of the RAM.)
I’ve run the profiler many times and that helped with the previous Helm issues, however I’m not sure exactly what to look for. In the following report from only a couple of seconds, I navigated up and down a list of org-headings in a 3.4k file. I expanded and closed those headings, each which took just under a second to respond. Not my expected behaviour, but also nothing problematic. I just wanted to create a quick example. In fact navigating the profiler report was more problematic where it paused a couple of times while I was selecting lines using visual line mode before the UI jumped about 15 lines to catch up.
- command-execute 468 42%
- call-interactively 468 42%
- funcall-interactively 468 42%
- spacemacs/helm-M-x-fuzzy-matching 356 32%
- let 356 32%
- call-interactively 356 32%
- funcall-interactively 356 32%
- helm-M-x 356 32%
- helm-M-x-read-extended-command 356 32%
- helm 356 32%
- apply 356 32%
- helm 356 32%
- apply 356 32%
- helm-internal 356 32%
- helm-read-pattern-maybe 332 30%
- read-from-minibuffer 228 20%
- timer-event-handler 160 14%
- apply 160 14%
+ #<compiled 0x1fe4fe33b4e9> 155 14%
+ auto-revert-buffers 5 0%
+ redisplay_internal (C function) 18 1%
evil-escape-pre-command-hook 2 0%
+ helm-update 9 0%
+ helm-execute-selection-action 22 2%
+ #<compiled 0x1fe4fe339e39> 2 0%
- org-cycle 112 10%
- org-cycle-internal-local 112 10%
- org-unlogged-message 112 10%
apply 112 10%
- httpd--filter 447 40%
- httpd/roam-data 443 40%
- org-roam-server-visjs-json 443 40%
- org-roam--path-to-slug 367 33%
- file-truename 341 31%
- file-truename 95 8%
+ file-truename 49 4%
file-relative-name 26 2%
+ json-encode 49 4%
+ org-roam-db-query 7 0%
+ xml-escape-string 6 0%
+ org-mode 5 0%
+ -distinct 5 0%
+ s-word-wrap 2 0%
+ org-roam-db--ensure-built 1 0%
+ httpd/current-buffer-data 3 0%
+ httpd-log 1 0%
+ timer-event-handler 58 5%
+ ... 48 4%
+ redisplay_internal (C function) 33 3%
+ helm-ff--cache-mode-reset-timer 15 1%
+ org-roam-server-find-file-hook-function 14 1%
+ ccm-position-cursor 8 0%
Should I be profiling over minutes or hours in order to produce something useful?
I’d really like to be able to have twice as many windows open if I could. Perhaps I just need to restart emacs every hour or so?
Any help would be greatly appreciated. Or, what is having 10 org-roam windows open at once like on your hardware?
Thank you for your time,
Patrick