分析行为不当的 Emacs Lisp 的技巧? [英] Tips for profiling misbehaving Emacs Lisp?

问题描述

我经常定制 Emacs.最近，我在我的 .emacs 配置中添加了一些东西，偶尔将我的 CPU 固定在 100%，但我真的不知道它是什么.

I customize Emacs a lot. Recently, I added something to my .emacs configuration that sporadically pegs my CPU at 100%, but I really don't know what it is.

如果我多次按下 C-g，最终我会在下方收到一条消息，询问我是否要自动保存我的文件，然后我是否要完全中止 emacs.如果我一直拒绝并继续按 C-g，最终我可以恢复正常运行 emacs.大约一个小时后，它会再次发生.

If I press C-g a bunch of times, eventually I'll get a message below the minibuffer asking me if I want to auto save my files and then if I want to abort emacs entirely. If I keep saying no and keeping pressing C-g, eventually I can get back to running emacs as normal. An hour or so later it will happen again.

我可以继续像我一样，评论我最近添加的各种东西，重新启动 emacs，试图缩小罪魁祸首，但进展缓慢.

I could keep going about like I am, commenting out various things I've added recently, restarting emacs, trying to narrow down the culprit, but it's slow going.

有没有办法可以直接分析 emacs 以找出占用 CPU 的 lisp 函数?

推荐答案

建议把debug-on-quit设置为t，这样你就可以找出Emacs的内容是一个很好的.您可以将其视为对单个样本进行抽样分析的一种形式:通常只需要一个样本即可.

The suggestion of setting debug-on-quit to t so that you can find out what Emacs is up to is a good one. You can think of this as being a form of sampling profiling with a single sample: often a single sample is all you need.

更新:从 24.3 版开始，Emacs 包含两个分析器.profiler.el 中有一个(新的)采样分析器，elp.el 中有一个(旧的)检测分析器.

Update: Starting with version 24.3, Emacs contains two profilers. There's a (new) sampling profiler in profiler.el, and an (old) instrumenting profiler in elp.el.

采样分析器记录在此.使用起来非常简单:

The sampling profiler is documented here. It's pretty straightforward to use:

要开始分析，请输入 M-x profiler-start.您可以选择按处理器使用情况、内存使用情况或两者进行分析.完成一些工作后，键入 M-x profiler-report 以显示您选择分析的每个资源的摘要缓冲区.完成分析后，键入 M-x profiler-stop.

To begin profiling, type M-x profiler-start. You can choose to profile by processor usage, memory usage, or both. After doing some work, type M-x profiler-report to display a summary buffer for each resource that you chose to profile. When you have finished profiling, type M-x profiler-stop.

以下是使用 的 cpu+mem 分析器会话的一些示例输出我维护的 Perforce/Emacs 集成.我扩展了最顶层的函数 (progn) 以找出 CPU 时间和内存使用的来源.

Here's some example output from a cpu+mem profiler session with the Perforce/Emacs integration that I maintain. I've expanded the topmost function (progn) in order to find out where the CPU time and memory use is coming from.

Function                                            Bytes    %
- progn                                        26,715,850  29%
  - let                                        26,715,850  29%
    - while                                    26,715,850  29%
      - let                                    26,715,850  29%
        - cond                                 26,715,850  29%
          - insert                             26,715,850  29%
            + c-after-change                   26,713,770  29%
            + p4-file-revision-annotate-links       2,080   0%
+ let                                          20,431,797  22%
+ call-interactively                           12,767,261  14%
+ save-current-buffer                          10,005,836  11%
+ while                                         8,337,166   9%
+ p4-annotate-internal                          5,964,974   6%
+ p4-annotate                                   2,821,034   3%
+ let*                                          2,089,810   2%

你可以看到罪魁祸首是c-after-change，所以看起来我可以通过本地绑定inhibit-modification-hooks到t围绕这个代码.

You can see that the culprit is c-after-change, so it looks as though I could save a lot of CPU time and memory by locally binding inhibit-modification-hooks to t around this code.

您也可以使用 Emacs Lisp Profiler.这是相当缺乏记录的:您必须阅读 elp.el 中的注释以了解详细信息，但基本上您运行 elp-instrument-package 以打开分析对于所有具有给定前缀的函数，然后elp-results 查看结果.

You can also use the Emacs Lisp Profiler. This is rather under-documented: you'll have to read the comments in elp.el for the details, but basically you run elp-instrument-package to turn on profiling for all the functions with a given prefix, and then elp-results to see the results.

这是在键入 Mx elp-instrument-package RET c-RET、字体化 4,000 行 C，然后运行 ​​elp-results(并使用 elp-sort-by-function 按调用次数排序):

Here's some typical output after typing M-x elp-instrument-package RET c- RET, fontifying 4,000 lines of C, and then running elp-results (and using elp-sort-by-function to sort by call count):

Function Name                  Call Count  Elapsed Time  Average Time
=============================  ==========  ============  ============
c-skip-comments-and-strings    107         0.0           0.0
c-valid-offset                 78          0.0           0.0
c-set-offset                   68          0.031         0.0004558823
c-end-of-macro                 52          0.0           0.0
c-neutralize-CPP-line          52          0.0           0.0
c-font-lock-invalid-string     20          0.0           0.0
c-set-style-1                  19          0.031         0.0016315789
...

在您的特定情况下，分析器不会立即提供帮助，因为您不知道哪个包有问题.但是，如果您可以进行猜测(或使用 debug-on-quit 来确定)，那么分析器可以帮助您详细诊断问题.

In your particular case the profiler doesn't help immediately, because you don't know which package is at fault. But if you can make a guess (or use debug-on-quit to find it for sure) then the profiler can help you diagnose the problem in detail.

这篇关于分析行为不当的 Emacs Lisp 的技巧?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！