emacs从26.0升级到26.3以后,helm-gtags在mini buffer中用tab键补全会卡很久

一直以来,用emacs和tuhdo大神的emacs + gtags + helm配置做日常的代码编辑和阅读器,其中有个配置甚为好用 ,‘M-.’ 配置为helm-gtags-dwim(该函数属于helm-gtags包),在mini buffer中可以先输入函数符号的部分前缀,进一步通过tab键,helm会给出候选函数对象给你选择,整个过程很顺畅。

问题是:升级到26.3以后,tab补全要等很久。希望能搞清楚、或者有什么手段可以搞清楚这个卡顿的原因。

helm-gtags-dwim + tab补全效果如下:

该函数的实现如下:

 1274 ;;;###autoload                                                                                                                                                         
 1275 (defun helm-gtags-dwim ()
 1276   "Find by context. Here is                                                                                                                                            
 1277 - on include statement then jump to included file                                                                                                                      
 1278 - on symbol definition then jump to its references                                                                                                                     
 1279 - on reference point then jump to its definition."
 1280   (interactive)
 1281   (let ((line (helm-current-line-contents)))
 1282     (if (string-match helm-gtags--include-regexp line)
 1283         (let ((helm-gtags-use-input-at-cursor t))
 1284           (helm-gtags-find-files (match-string-no-properties 1 line)))
 1285       (if (and (buffer-file-name) (funcall helm-gtags-symbol-at-point-function))
 1286           (helm-gtags-find-tag-from-here)
 1287         (call-interactively 'helm-gtags-find-tag)))))

求emacs hacker帮忙解答,不想与新版emacs失之交臂啊

为什么不升级到Emacs 27.1 呢?

为什么不升级到Emacs 27.1

用的ubuntu默认提供的软件包版本

有没有什么办法可以调试emacs的卡顿问题,定位到具体的卡顿点在哪里

我很少用Linux,所以这部份的卡顿不是很了解。
你用26.0 不卡顿? 到了26.3才卡吗?
你可以用二分法,去掉一半的配置,或者直接用一个空的配置试试看是不是还开顿。如果不卡顿,就是你的配置问题了。找到具体是哪个包造成的,再去分析,或者上这个包的仓库上看看,有没有人报issue。

这个卡顿只涉及我图中的这个函数,而且不在这个函数中使用tab就没问题,如果用旧的软件包和新的emacs,有很多初始化错误,所以软件包也是跟随emacs升级过的,对比了旧版本和新版本的这个函数实现差异,没有区别。所以想知道emacs有没有什么调试手段。