设置debug-on-quit
为t
以便您可以了解 Emacs 正在做什么的建议是一个很好的建议。您可以将其视为使用单个样本进行抽样分析的一种形式:通常您只需要一个样本。
更新:从 24.3 版开始,Emacs 包含两个分析器。中有一个(新的)采样分析器profiler.el
,和一个(旧的)仪器分析器在elp.el
.
采样分析器在此处记录。使用起来非常简单:
要开始分析,请键入M-x profiler-start
。您可以选择按处理器使用情况、内存使用情况或两者进行分析。完成一些工作后,键入M-x profiler-report
以显示您选择分析的每个资源的摘要缓冲区。完成分析后,键入M-x profiler-stop
.
这是我维护的带有Perforce/Emacs 集成cpu+mem
的分析器会话的一些示例输出。我扩展了最顶层的函数 ( ),以便找出CPU 时间和内存使用的来源。progn
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
周围的代码来节省大量的 CPU 时间和内存。
您还可以使用 Emacs Lisp Profiler。这是相当不足的记录:您必须阅读注释以elp.el
了解详细信息,但基本上您运行elp-instrument-package
以打开具有给定前缀的所有函数的分析,然后elp-results
查看结果。
M-x elp-instrument-package RET c- RET
这是键入、字体化 4,000 行 C,然后运行elp-results
(并使用elp-sort-by-function
按调用次数排序)后的一些典型输出:
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
它来确定),那么分析器可以帮助您详细诊断问题。