我在native-comp合进master后就开始使用emacs master分支。好久没用 C-h m 然后突然有一天发现打开它需要10s。emacs -Q打开后这个命令也需要将近1s，无法忍受。不知道大家是否也有同样的情况。
读了读源码，发现疑似是 substitute-command-keys 的锅，因为在某个时刻，这个原本是C函数的接口被高效的Elisp语言重写并合进了master分支，现在配置复杂一些（Spacemacs），任何major mode打开 C-h m 都是5秒以上 
于是乎，不能忍又不知道怎么解决的我，就找到了merge的结点，checkout到过去，从此告别master。（即标题所说的解决方案 
）
大伙的配置下会出现我说的这个情况吗？
是挺慢的但是没到10s，大概一两秒
应该是Emacs 28的regression：#45379 - 28.0.50; Degraded Performance of describe-buffer-bindings - GNU bug report logs 很久前给了个patch但没有合并进主线，几天前合并了
谢谢，我看看哈。所以就是中秋假期这几天合并的呗。。我也是醉了，节前我实在忍不了了就回退重编了，结果就过节的时候修复了。感觉有被针对 
咦，原来这个bug是你报的呀 
我 9 月17日编译的 master 分支，没踩到这个 bug 
使用的是这个 commit ：
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c6eb114a42922af18818dce7317238e0af776958
昨晚编译了5d96fad27master-commit. C-h f 依然卡出10S的节奏。 on windows. 这个问题真的被修复了吗？
启动emacs后，第一次卡，再 C-h f 就比较平滑了。
你看看 load-path 这个变量的大小，我原来研究过 C-h m 的源码，当 load-path 这个变量特别大的时候，C-h m 就会非常卡，Linux最少需要5秒。
如果是这个原因，就删除那些没必要的 path。
我研究这个问题的初衷是 EAF 有很多 npm 的目录，这些目录把 load-path 弄到几万的大小，导致 C-h m 非常卡, 最后我专门给EAF写了一个排除 npm 目录的 load-path-recursively 函数。
今天重新在 Windows msys2 的 mingw64 上编译了最新的 master 分支，没楼主说的这个问题。 http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4c891b2a05748c7a16ac6ac94f01e017187c4949
git clone --depth=1 https://git.savannah.gnu.org/git/emacs.git
cd emacs
./autogen.sh
./configure --without-dbus
make -j$(nproc)
make install prefix=/c/emacs28
cp $( pacman -Ql mingw-w64-x86_64-{libtiff,giflib,libpng,libjpeg-turbo,librsvg,libxml2,gnutls} | grep bin/.*\.dll$ | awk '{print $2}' ) /C/emacs28/bin
谢谢答复。 不过我的load-path 才130 个元素。算是比较小吧。
C-h f CPU 统计：
C-h f 的 profiler 中 Info-find-file 为什么会这么长？不知道正常不？
------------更新----------------
可能是 helpful 这个包加载表现太差的原因。不用helpful，响应还是比较快的。
我在windows上使用emacs。这个问题可能和 straight.el 中的 ಠ_ಠ 有关系。
详细见：Emacs hangs on Windows due to straight-ಠ_ಠ · Issue #877 · radian-software/straight.el · GitHub 引来了 Eli Zaretskii 的一场争辩。
但最终还是没有找到问题的根本原因。总之是 字体解码 方面的问题。
(when IS-WINDOWS
(set-fontset-font t #x02F0 "Unifont")
;; NOTE: Unifont can display #x0CA0 but Emacs still choose 'Nirmala UI'
(set-fontset-font t #x0CA0 "Nirmala UI")) ; fix slow when 'M-x str' under Windows, because it will display `straight-ಠ_ಠ-mode'
Straight. 把这个字符删除掉了。
是的，我也看到了。不过最终解决应该还是得Emacs改进下字体查询得机制吧。 比如上面得#x02F0就是emacs-rime里的默认的字符，也会导致僵死。
但开发者似乎并不认为是emacs的机制问题。