131–138 of 138 posts
Earlier quoted context omitted.
Can't help as I'm on Linux (also I use ivy/avy/counsel and not consult/marginalia/vertico).
Out of curiosity, why did you reply?
Earlier quoted context omitted.
Forgive my ignorance, but why would doing all of the application work on a single thread make more sense 35 years ago?
The first consumer processors with multiple cores came out around 2005. Before there were multiple cores in consumer machines, there was no reason to implement concurrency in a way that would scale to multiple cores.
They would've been wildly forward-looking if they had figured this out 35 years ago though.
Earlier quoted context omitted.
It's not having lots of things installed. It's actually using them. Basically how much custom elisp is running in your buffer.
With respect, I think you're confused. But even if I'm right, that's OK, software is complicated, and it took me a while to get these things straight. Multiple installed emacs packages do not execute their code simultaneously unless they are using something like run-with-timer to schedule tasks on the event loop. Can you give me an example of an emacs package that causes custom elisp to be "running in your buffer" co…
Yes, that's accurate, but that's the whole problem. The code executes sequentially, so each custom execution adds latency. It's not unusual to have elisp from several packages executing with every keypress.
Earlier quoted context omitted.
A lot of this is down to configuration. For example, you say “Emacs TRAMP uses one ssh connection per command”, but that’s only true if you’re not using the ControlMaster SSH option. Add this to your ~/.ssh/config file: ControlMaster auto ControlPersist yes ControlPath ~/.ssh/control/%C Then run mkdir -p ~/.ssh/control/, if you haven’t already. Why this isn’t the default I don’t know, but once configured correctly yo…
> Why this isn’t the default I don’t know (…) It is, it has been for a while. Check the TRAMP FAQ for details when it is being used automatically (grep for "ControlMaster"): https://www.gnu.org/software/emacs/manual/html_node/tramp/Fr...
Earlier quoted context omitted.
To outsource things step-by-step to lightweight processes seems to be a good incremental way to disentangle. Perhaps one could protect access to resources not initially invented by Emacs packages (Emacs core?) and make Emacs query a separate process, without a package knowing about that, so that it channels all communication to the separate process. Then deprecate directly the resource at some point and offering a mo…
It indeed isn't. Some Emacs packages use that approach, and others are well-known to employ Unix utilities to do the legwork. Maven and Gradle both have daemon modes. Unfortunately, all these integrations are custom, so there is no chance for it to take off. Ycmd is also worth mentioning. What really made the difference is that VS Code uses LSP to integrate languages. Instead of dozens of ad-hoc integrations, there i…
Earlier quoted context omitted.
> Multiple installed emacs packages do not execute their code simultaneously unless they are using something like run-with-timer to schedule tasks on the event loop. It's true that few things run in the background constantly. You can check for that easily, with M-x list-timers. On my work laptop, my most feature-packed Emacs instance, I currently have three timers active (and 11 waiting for a trigger). Those three ar…
Ah, thanks for explaining that so clearly and thoroughly. You're right that I was forgetting hooks. (And I learned something else from what you wrote -- that often a library will have it's triggered function merely enqueue a task. Of course that makes sense but I'd forgotten that in an emacs context (whereas I might have thought of it in a backend web dev context)). Two questions/comments: 1. I had it in my head that…
However, font-lock-mode never executed in a separate preemptive thread.
Earlier quoted context omitted.
With respect, I think you're confused. But even if I'm right, that's OK, software is complicated, and it took me a while to get these things straight. Multiple installed emacs packages do not execute their code simultaneously unless they are using something like run-with-timer to schedule tasks on the event loop. Can you give me an example of an emacs package that causes custom elisp to be "running in your buffer" co…
> Multiple installed emacs packages do not execute their code simultaneously unless they are using something like run-with-timer to schedule tasks on the event loop. It's true that few things run in the background constantly. You can check for that easily, with M-x list-timers. On my work laptop, my most feature-packed Emacs instance, I currently have three timers active (and 11 waiting for a trigger). Those three ar…
524 57% - kill-all-local-variables
56 6% + magit-wip-after-save-mode-cmhh
56 6% + global-evil-quickscope-mode-cmhh
56 6% + global-eldoc-mode-cmhh
52 5% + global-page-break-lines-mode-cmhh
52 5% + global-font-lock-mode-cmhh
48 5% + smartparens-global-mode-cmhh
44 4% + global-prettify-symbols-mode-cmhh
40 4% + magit-auto-revert-mode-cmhh
40 4% + global-tree-sitter-mode-cmhh
40 4% + evil-mode-cmhh
40 4% + global-evil-collection-unimpaired-mode-cmhh
(Also, half the time when I run the profiler, the culprit ends up being evil-mode. Unfortunately it's so useful …)
Earlier quoted context omitted.
> Multiple installed emacs packages do not execute their code simultaneously unless they are using something like run-with-timer to schedule tasks on the event loop. It's true that few things run in the background constantly. You can check for that easily, with M-x list-timers. On my work laptop, my most feature-packed Emacs instance, I currently have three timers active (and 11 waiting for a trigger). Those three ar…
Similarly, I wanted to check what was taking up time on redoing org-agenda, profiler says the majority of the time is spent doing `kill-all-local-variables` 524 57% - kill-all-local-variables 56 6% + magit-wip-after-save-mode-cmhh 56 6% + global-evil-quickscope-mode-cmhh 56 6% + global-eldoc-mode-cmhh 52 5% + global-page-break-lines-mode-cmhh 52 5% + global-font-lock-mode-cmhh 48 5% + smartparens-global-mode-cmhh 44…
As it turns out, these are automatically created by `define-globalized-minor-mode' macro - per docstring, it's used to define a global mode for buffer-local minor modes. I.e. that's how you get all these `global-XXX-mode` functions that turn on XXX-mode in every (relevant) buffer.
One of the things this macro does is create a `global-XXX-cmhh' function, and attaches it to `change-major-mode-hook', which is invoked by `kill-all-local-variables' whenever buffer's mode is changed. I imagine that, as part of generating org mode's agenda, files get opened and modes get switched a lot. Curiously, it also seems that (digging into `kill-all-local-variables' source in C), each call to it forces mode-line redisplay, so further computation may be caused by whatever is in your mode line (which can also be nontrivial). I haven't checked that though, maybe it redisplays mode line only once.
Thanks for bringing this up, it's another place where pretty much every mode stuff some hook, that I didn't know about :).
EDIT: curiously enough, I just profiled my agenda - both doing from scratch and redoing it - and `kill-all-local-variables' isn't even on its radar. I wonder what runs in your hooks (and/or modeline) then. The result from refreshing an existing agenda was roughly what I expected. Building it anew, after killing all open org buffers, was interesting. In my case, 69% of total time was spent opening files (`find-file-noselect'), before even doing any mode switching. In that, `projectile-find-file-hook-function' accounted for 50% of total agenda building time, half of that spent updating the mode line!
From what I see, it's just trying to determine the project to which a file belongs. I'll probably look for an option to make projectile stop being interested in files that aren't in the "known projects" subtrees without explicitly instructing it so.