It is very common to profile Emacs with profiler-start, profiler-stop and profiler-report when you experience abnormal behavior of Emacs, such as input latency.But I've noticed that many people seemed to call profiler-stop interactively, which could be interfered by their completion framework when using M-x.

There is an example:

225  87% - command-execute
212  82%  - byte-code
212  82%   - read-extended-command
212  82%    - completing-read-default
212  82%     + apply
 13   5%  - funcall-interactively
 12   4%   - execute-extended-command
 12   4%    - command-execute
 12   4%     - funcall-interactively
  7   2%      + profiler-start
  1   0%   + next-line
 30  11% + ...
  2   0% + redisplay_internal (C function)
  1   0% + org-latex-impatient--prepare-timer

It illustrates that the vast majority of the results are completing-read-default, which are used by minibuffer completion, such as vertico and ivy. And the real bug is covered when you would like to debug input lag.

And there are two ways of calling profiler-stop non-interactively:

• Using eval-expression. Switch to scratch buffer insert (profiler-stop) then M-x profiler-start with some debuging. After finish the stuff, C-x C-e after the (profiler-stop) s-expression.
• Make a keybing. (global-set-key (kbd "<f5>") #'profiler-stop)

The report below shows the difference:

16  36% + redisplay_internal (C function)
        13  29% + command-execute
         8  18% + timer-event-handler
         3   6% + org-latex-impatient--prepare-timer
         2   4% + ...
         1   2%   winner-save-old-configurations
         1   2% + erc-server-filter-function