Did you try the builtin profiler?

Two things I can recommend : upgrading to the latest emacs distribution for your platform, and starting with an empty config to narrow down the issue

It’s should hopefully be easy to figure out with the profiler: just run profiler-start select cpu and do whatever triggers it then run profiler-stop and profiler-report

You then get a list of timings you can drill down into

Usually the fn names give a pretty good hint at what’s the offender

I can try to help you with this. If you would like to discus and arrange a meeting, you can DM me. 🙂

@U050SC7SV i tried the "profile start" function for CPU and memory, followed by re-creating an instance of emacs going to 100% CPU, followed by issuing "profile report" emacs command. I'll share the reports below and try to create another today to re-exam them. However, the reports, as I'll explain shortly, seemed to tell me nothing. The way they told me nothing is as follows: • the CPU was busy on the program called "..." which I could make nothing of • memory was busy on "command execute" which is what I believe is called when you call a shell command from emacs, which I never did in the session and saw no way to find out what shell command was called or what program called it, so again I could make nothing of it. • The memory also spent some time on #<compiled -0xc2e88094faf6d07>, which is also meaningless to me. Here are the reports. cpu profile report

53106  96% + ...
         669   1% + timer-event-handler
         615   1% + command-execute
         224   0% + redisplay_internal (C function)
          49   0% + cider--help-echo
          25   0% + #<compiled -0xc2e88094faf6d07>
          17   0% + beacon--post-command
          14   0% + tooltip-show-help-non-mode
           9   0% + evil-activate-visual-state
           8   0% + evil-repeat-pre-hook
           8   0% + evil-activate-visual-state
           4   0% + global-hl-line-highlight
           4   0% + flyspell-post-command-hook
           4   0% + global-spacemacs-leader-override-mode-check-buffers
           3   0% + lsp--post-command
           1   0%   winner-save-old-configurations

1,092,257,088  52% + command-execute
    626,955,725  29% + #<compiled -0xc2e88094faf6d07>
    329,124,244  15% + timer-event-handler
     39,824,685   1% + redisplay_internal (C function)
      8,496,750   0% + cider--help-echo
        960,645   0% + beacon--post-command
        457,088   0% + winner-save-old-configurations
        344,989   0% + flyspell-post-command-hook

@U06F82LES Isolating the problem is a good idea and one I have been trying in various forms. However, nearly everything installed in my emacs config atm are things that I need to be productive. If I had to guess, I think the issue is either autocomplete, auto-balancing tags, or cider functionality. I need all of those in some form, and they are all something that nearly everyone in the clojure community relies on, so I'm very confused why my experience of hitting 100% CPU is unique. One outlier here is that I'm on Ubuntu, and I imagine there are far more people on Mac OS. To lend some very small credibility that the os could make a difference, cider bug reports do want you to include your Operating system. Again, i'm struggling to narrow down the problem, and as you said, i need to take more steps to doing that. The straw that broke the camels back for me was that it still happens on a brand new computer, i was secretly hoping a new computer with fair better hardware (on paper at least), new OS install, new emacs install, would as you suggest narrow down the issue or remove some pre-existing issue.

What other packages do you use? i had huge problems with lsp in the past.

Did you try to expand the command-execute?

(Click on the +) sorry if it’s obvious

The only time i got cpu spin to 100% was with 2 packages competing to reformat the buffer back & forth

I think a good way to debug this is to disable all your emacs addons and customisations and then slowly add them back in to find out what is causing it. I imagine a vanilla emacs install wouldn't do this, so it is likely to be something in a package or customisation.

@U1EP3BZ3Q here is my https://github.com/drewverlee/spacemacs.d/blob/main/init.el, I'm not sure how to just list all the packages that I use, I searched for a bit but the information was conflicting and a couple popular answers didn't give good results. spacemacs has a lot of functionality I'm used to so I was hoping to continue with that, however, I also have doom setup fairly well but it also has the same lag issue. Yes I'm using lsp

I use emacs and cider on ubuntu without issue - I don't update emacs or packages that often so I could be using older versions.

@U0DJ4T5U1 try to turn off lsp and check what happens.

as @UJVEQPAKS says, disable (or enable) stuff one by one

Next time I run into it, ill disable LSP and see if it goes away.I would have to disable lsp functionality and then re-configure cider functionality.

@U050SC7SV i tried and wasn't successful at expanding command-exectue. i clicked using my mouse the + (UI didn't indicate it was clickable at all) as well as the function name e.g command execute (which was clickable aka underlined in blue). I also hit enter on both from my keyboard. Neither did anything. I guess ill check the docs 🤷 for how to interact with the menu.

so the cpu spike after i connect to a cider repl, but stays even if I quit the connection. If I profile right around the spike this is what I see: bytes % function

355,847,092  53% + #<compiled -0x15a4e8096a5ebfa9>
    192,280,933  29% + command-execute

26857  90% + #<compiled -0x15a4e8096a5ebfa9>
 674   2% + timer-event-handler

it doesn't spike when i make the connection, it just starts happening as I move around the code after I did it.

Could it be code base that is the problem? (e.g. test with a different/smaller codebase). Perhaps the static analysis is being stuck in an infinite loop or generating long lines of text which emacs doesn't like.

I think it is related to the clojure project. I can't get it to happen on a small clojure project. And even I just connect to the big clojure project, then switch to a small one, with a new repl and start moving around, that starts lagging. Like somehow emacs is getting slowed down just being connected to it. But again, "isolation" is really hard. especially when I don't have a constant way to trigger it.

It could be a regex going crazy on a particular input file

Perhaps delete half your namespaces and see if it still triggers - if it doesn't delete the other half.

Yeah you need to find a way to repro and bisect

Perhaps try running linters, run clojure tests, run test coverage, run lein check to see if any of these chokes on the codebase. Could also use this as an opportunity to refactor the codebase (e.g. break down into smaller projects) and run tests on each of these separately.

John, whose emacs config i tend to closely follow, is https://clojurians.slack.com/archives/CJTRRQ857/p1678046014176219?thread_ts=1677851671.284309&amp;cid=CJTRRQ857. I thought I was seeing the same thing. I had a tiny project where I was just messing with a comment block, but then it seemed to happen less often on smaller projects, so I wasn't sure. But it would make sense that a larger project might tip the scale on the problem more constantly because it has more to parse.

profile report I get from the same issue is

16148  96% - ...
       16090  95%  + #<compiled 0x7a94b7e337a224a>
          56   0%    Automatic GC
           2   0%  + eldoc-documentation-default
         453   2% + command-execute
         113   0% + redisplay_internal (C function)
          35   0% + timer-event-handler
          15   0% + evil-activate-visual-state
          12   0% + #<compiled 0x170f52af476e2c03>
           7   0% + #<compiled -0xb7e6fb840211f99>
           5   0% + evil-repeat-pre-hook
           2   0% + evil-normal-post-command