Help diagnosing lag when opening a `.el` file

Lately, since switching to using Emacs 28 (using the `emacs-plus` build), I run into the following issue: when simply trying to open a file, Emacs freezes for a few seconds before doing so. Now: - I've had this happen multiple times when opening a single `.el` file while visiting a buffer with a different `.el` file on, so there should be no delay coming from running any mode-related hooks etc, at least as far as I understand these things. - I've had this happen long after starting an Emacs session, so any package being loaded with a `:defer n` call (via `use-package`) should have been loaded. I've been trying to use the one tool I sort of knew of for this, `explain-pause-mode`, but something appears to be wrong with the package but for some reason the package isn't working anymore. I've now had the profiler start by default and tried to look at the profiler report right after I notice the lag, but that hasn't given me any clues. I'm thinking of resetting the profiler every few seconds or so to see if that helps, but I'm wondering if anyone here knows of another way to figure out what's going on. I've been reluctant to bisect my init since as I said before sometimes hours go by without running into this problem.

If it's when opening a file, it's something in that file's mode's hooks, probably. Is it always `.el` files? Could also be a bug related to `auto-mode-alist`, though if something's bugged and filling that with a zillion entries it'd probably be more noticeable.

Profiler running all the time is probably not a good idea. It’ll just slow things down, possibly use more memory, and make things worse for you by putting more pressure on the garbage collector. I could be wrong here—never tried it myself. Very often, random pauses I get have been due to network pauses. E.g. some program that some mode executes all the time is usually fast, but might hang due to a network hiccup. This, and also auto-revert-mode with files on a network file system. Setting “debug on quit” and pressing Ctrl-g during a hang might find a culprit.

Thanks for the pointer about the profiler. And thanks for the suggestions. I’ll look into the auto revert possibility. Question for you: is setting debug-on-quit significantly different than setting debug-on-entry on a function that calls keyboard-quit? The latter seems like a less annoying option since it won’t call the debugger every time I call keyboard-quit in other contexts…

Thanks. I’ve looked into those but no luck. I think I’ve noticed this mostly on .el files, yes, but I haven’t been switching between other files like I have between `.el` files…

Yeah, debug-on-quit can get annoying if always on. :-) I think both debug-on- functions are similar in effect. debug-on-quit helps when you have no idea where the problem is, and debug-on-entry is useful when you know the function you'd like to debug (for pretty clear reasons!). I don't know how you'd use debug-on-entry to diagnose a problem that you don't know the cause of, though. :-) Another idea: if you see the stall only when opening files, you could use "around" advice on find-file (and friends -- there are similar variations) to bind debug-on-quit t for just that one function. Clearly, going down this path gets means you're dealing with the lisp end of things. I'm always looking stuff up to figure out how to actually do any of these things; don't get the impression that any of this should be at the tip of your fingers.

Love the ‘around advice’ idea. Thanks!