Redundant calls leads to slow performance in forge-dispatch
#712
Replies: 2 comments 2 replies
-
Yes, I am aware. But after working on Transient and Forge for a long time I wanted to work on other things for a while. That will allow me to find good solutions once I return my focus here. I have some experimental work that allows storing information in an environment that can be shared by all code that sets up a prefix. Kinda like |
Beta Was this translation helpful? Give feedback.
-
I am glad you are thinking about good potential solutions. In the meantime, I am using this code to workaround the issue: (with-eval-after-load 'magit
(defun transient-setup-cache (fn &rest args)
(let ((magit--refresh-cache (list (cons 0 0))))
(apply fn args)))
(advice-add 'transient-setup :around #'transient-setup-cache)) This makes |
Beta Was this translation helpful? Give feedback.
-
Thank you for creating this package. I have been using forge on a large repo, and in the magit dispatch popup it will typically take about 15 seconds after I hit
N
(forge-dispatch
) before the transient menu will show up. I wondered why it took so long, so I enabledmagit-process-extreme-logging
to see the commands. Here is the result:There are 176 calls to git, but only 6 unique ones. Each set of operations is getting called 22 times. And that is just to open the dispatch menu. It looks like these are part of calls to
forge-get-repository
. That function does usemagit--with-refresh-cache
, but the cache is never initialized so it never gets used. I was going to try and initializemagit--refresh-cache
myself but I couldn't figure out how to to do that intransient-define-prefix
.Magit v4.1.0-11-g7370a47a, Transient 0.7.4, Forge 0.4.4, Git 2.46.0, Emacs 29.4, darwin
Beta Was this translation helpful? Give feedback.
All reactions