提示错误Emacs Lisp？ [英] Tips for profiling misbehaving Emacs Lisp?
问题描述
如果我多次按Cg，最终我会收到下面的消息，这个minibuffer问我是否要自动保存我的文件，然后如果我想要完全中止emacs。如果我不断的说，不要按C-g，最终我可以恢复正常运行的emacs。一小时左右，它会再次发生。
我可以像我一样继续下去，评论我最近添加的各种事情，重新启动emacs，试图缩小呃，呃，这是慢的。
有没有办法我可以直接配置emacs来弄清楚什么是lisp的功能呢？ >
建议将 debug-on-quit code> t ，以便您可以找出Emacs是一个好的。您可以将此视为采用单一样本的抽样分析形式：通常只需要一个样本。
更新：从版本24.3开始，Emacs包含两个剖析器。在 profiler.el 中有一个（新的）采样分析器，以及 elp.el 中的（旧）仪器分析器。
抽样分析器是记录在这里。使用以下方法非常简单：
要开始分析，请键入
Mx profiler-start。您可以选择通过处理器使用情况，内存使用情况或两者进行配置。执行某些工作后，键入M-x profiler-report以显示您选择配置文件的每个资源的摘要缓冲区。当您完成配置文件后，键入Mx profiler-stop。
例如从 cpu + mem > Perforce / Emacs集成。我已经扩展了最大的功能（ progn ），以便找出 CPU时间和内存使用来自哪里。
函数字节％
- progn 26,715,850 29％
- 让26,715,850 29％
- 而26,715,850 29％
- 让26,715,850 29％
- cond 26,715,850 29％
- 插入26,715,850 29％
+ c-after-change 26,713,770 29％
+ p4-file-revision-annotate-links 2,080 0％
+ let 20,431,797 22 ％
+以交互方式通话12,767,261 14％
+保存当前缓冲区10,005,836 11％
+而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 / a>。
您还可以使用Emacs Lisp Profiler。这是相当不明确的：您必须阅读 elp.el 中的详细信息，但基本上您运行 elp-instrument-包可以使用给定的前缀打开所有功能的分析，然后使用 elp-results 查看结果。
键入 Mx elp-instrument-package RET c-RET 之后的一些典型输出，将4,000行C，然后运行 elp-results （并使用 elp-sort-by-function 按呼叫计数排序）：
功能名称呼叫计数已用时间平均时间
============= ================ ========== ============ ============
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-宏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 确定找到它），那么分析器可以帮助您详细诊断问题。
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.
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.
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.
Is there a way I can profile emacs directly to figure out what lisp function is hogging the CPU?
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.
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:
To begin profiling, type
M-x profiler-start. You can choose to profile by processor usage, memory usage, or both. After doing some work, typeM-x profiler-reportto display a summary buffer for each resource that you chose to profile. When you have finished profiling, typeM-x profiler-stop.
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%
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.
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.
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
...
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屋！
