开了native-compilation的emacs28搜索子字符串速度只有emacs27的五分之一

在确认所有优化都已打开, 测试以下代码,

(let* ((gc-cons-threshold most-positive-fixnum))
  (message "%s vs %s"
           (benchmark-run-compiled 5
             (pyim-dregcache-search-word-code "wo-m"))
           (benchmark-run-compiled 5
             (pyim-dregcache-search-word-code "ai"))))

Emacs 27结果,

(4.94237456 0 0.0) vs (4.940236186 0 0.0)

Emacs 28结果,

(24.107471964000002 0 0.0) vs (24.143487565 0 0.0)

pyim-dregcache-search-word-code就是一个简单的搜索子字符串,没有用什么算法。 有道友能分析一下吗?

测了一下,就是string-match特别慢。是C实现的.和native compilation没有关系。

(setq content
      (with-temp-buffer
        (let ((coding-system-for-read 'utf-8-unix))
          (insert-file-contents "3g.txt"))
        (buffer-string)))

(message "content length=%s" (length content))
(let* ((gc-cons-threshold most-positive-fixnum))
  (message "%s vs %s"
           (benchmark-run-compiled 1
             (string-match "aaaaa" content))
           (benchmark-run-compiled 1
             (string-match "bbbbb" content))))

3g.txtbase64 /dev/urandom | head -c 3000000000 > 3g.txt生成。

3 个赞

前几天重新编译了最新的master分支代码,没有开native comp的选项, 用着没什么区别。

建议发到emacs-devel邮件组

1 个赞

是我的问题.gcc的-O2 CFLAGS 忘记开了.:grinning_face_with_smiling_eyes:

我刚想说忙猜 28 是 debug 版。。。 :smiley:

塞翁失马. 逼得我把pyim的dregbackend引擎(用于拼音输入法)的算法改进了一下,现在pyim速度提高了10倍. 我主要痛点就是pyim在emacs上输入卡.

9 个赞

哈哈哈太强了大佬

速度提升之后,卡顿有改善吗?

在未优化的emacs28上,pyim 速度恢复了正常。

2 个赞

28的确bug挺多,比如默认的python的正则高亮直接崩溃了。。。。。但是又不是很想用elisp-tree-sitter,毕竟tree-sitter马上就要融于core里了,感觉用第三方的没啥前途

先用着,合并了再去掉呗

用29吧,还有遇到bug请报告,没人报告当然不会有人去修

话说,Emacs 29 的预览版很久没有更新了!

官方从来没打过emacs 29的tag:

用29的话建议至少每周从最新源码编译一次新版。

-O2 是编译emacs时没开吗?还是 native-compilation jit 有单独的 CFLAGS 参数?