Fedora 34下Emacs 27.2偶发启动卡顿数秒问题求助

常见成因 #

该现象属于典型的冷启动磁盘缓存失效导致的延迟：关闭Emacs1分钟后启动属于冷启动，系统页缓存（page cache）、目录项缓存（dentry cache）中已清理了Emacs依赖的资源，需要重新从磁盘读取；立即重启属于热启动，资源还留存在缓存中，所以无卡顿。结合你的环境，概率最高的成因如下：

• Fedora 34 预装的rpmdev-init.el会批量注册RPM相关文件的模式匹配规则，触发全量MIME类型数据库加载，冷启动时/usr/share/mime下的零碎缓存文件需要从磁盘读取，耗时较长
• GTK3 前端加载主题资源、字体config缓存时触发大量随机IO，冷启动时耗时陡增
• 部分桌面环境默认会让Emacs启动时查询系统图标主题、在线配置等资源，网络/DBus调用超时会额外增加耗时

strace日志具体排查方向 #

你可以按以下优先级排查两份日志的差异：

1. 先筛选高耗时系统调用
   执行以下命令直接提取冷启动日志中耗时超过100ms的调用，定位卡慢点：

   awk '{if (substr($NF,2,length($NF)-2) > 0.1) print $0}' emacs_slow.strace
   

2. 重点关注三类调用的差异
   • openat/access/stat：如果冷启动日志中存在大量重复尝试访问不存在的字体路径、图标资源、配置文件的记录，说明这些无效查询触发了磁盘IO，热启动时查询结果已存入dentry缓存，所以无延迟
   • poll/select/recvmsg/sendmsg：如果这类调用的耗时占比最高，说明卡顿来自DBus通信、网络请求、X11/Wayland compositor交互超时
   • mmap/read：如果是读取/usr/lib64下的.so共享库、/usr/share/emacs下的lisp源文件耗时高，说明对应资源未进入页缓存

快速验证方案 #

你可以先通过以下操作快速定位根因：

• 临时重命名/usr/share/emacs/site-lisp/site-start.d/rpmdev-init.el，重启测试冷启动耗时，排除该配置的影响
• 执行fc-cache -fv重建字体缓存后，再测试冷启动速度
• 尝试用终端无GUI模式启动emacs -nw foo.txt，如果无卡顿则可以确认是GTK3前端资源加载导致的问题

内容的提问来源于stack exchange，提问作者infisxc