这么牛逼的吗。 对比lisp的性能如何
这个 POC 还对不不出性能来,我觉得一些复杂计算 deno 肯定有优势。
突然想起来,是不是应该制定一套 Emacs RPC 规范,包括通用部分和括展部分。这样所有同外部进程的通讯都可通过同一套东西来进行,只需要一个 EPC Sever 在 Emacs 里面,其他的通过括展来做。
似乎已经有了,GitHub - kiwanami/emacs-epc: A RPC stack for Emacs Lisp, LSP-Bridge 也用了 EPC。但这只是协议层吧,在这之上应该加上通用的变量和函數,比如 get-emacs-var、ping、eval-in-emacs 等等。
不知道这个 deno-bridge 属不属于这个范畴。
EAF/lsp-bridge用的是 epc + sexp 通讯。
deno-bridge 用的是 WebSocket。
其实我觉得 WebSocket 更好一点, 因为各种语言都可以支持, EPC的问题是, 如果 EPC 的作者不支持, 其他语言要支持 EPC, 就要写一套支持 EPC 的 server/client。
RPC 本质是双向通讯, 两种语言都要实现 server/client 。
自从 google.cn 挂了以后, youdao和baidu的翻译质量都堪忧, 这段时间我的 insert-translated-name 插件基本就是挂的。
今天基于 deno-bridge 和 puppeteer 写了一个 DeepL 的翻译后端, 基本可以替代原来 Google 翻译的质量。
用 Puppeteer 的优点是, 直接后台跑了一个浏览器来抓取 DeepL 网页的翻译结果, 这样的好处不需要弄DeepL API Key (DeepL key 注册需要信用卡, 还不能用中国的,限制还多) 就能免费的使用其翻译结果。 缺点是,第一次翻译比较耗时。
第一次以后的查询基本上就是秒回的性能, 非常的方便。
相关的实现可以查看:
@P233 最新版的 deno-bridge 不需要再设置端口号了, deno-bridge会自动分配 localhost 没用的端口, 避免手动设置以后插件多了冲突。
顺便分享一下Elisp版的函数:
(defun deno-bridge-get-free-port ()
(save-excursion
(let* ((process-buffer " *temp*")
(process (make-network-process
:name process-buffer
:buffer process-buffer
:family 'ipv4
:server t
:host "127.0.0.1"
:service t))
port)
(setq port (process-contact process))
(delete-process process)
(kill-buffer process-buffer)
(format "%s" (cadr port)))))
感谢大佬,正好明天有时间,可以专心写一写
最新版 TypeScript 的 unpack 有所调整, 请参考 README demo
目前开发完成度在 1/3 左右,跟 elisp 写的 emmet-mode 比有肉眼可见的提速。
fork 了 emmet-mode 了一份,改来改去恼火,现在一方面复用了 emmet 的全部功能,一方面又能按自己的需求随意拓展,很开心😄
最新版增加了对 ansi-color 的支持, console.log 打印的时候, Emacs端不再显示乱码。
这个插件很有意思,给 Neovim 添加鼠标手势:
哈哈哈哈, 欢迎写插件, 但是我完全不用鼠标。
我太菜了,连基本的快捷键都没掌握呢。
我也不用鼠标好几年了,但是离不开触控板
厉害! zsbd
v8 的性能很强悍啊
;; https://www.gnu.org/software/emacs/manual/html_node/elisp/Speed-of-Byte_002dCode.html
(defun silly-loop (n)
"Return the time, in seconds, to run N iterations of a loop."
(let ((t1 (float-time)))
(while (> (setq n (1- n)) 0))
(- (float-time) t1)))
#[defun]
fn silly_loop(env: &Env, n: i64) -> Result<Value<'_>> {
let start_time = SystemTime::now();
let mut i = n;
while i > 0 {
i = i - 1;
}
let end_time = SystemTime::now();
let difference = end_time.duration_since(start_time)
.expect("Clock may have gone backwards");
env.message(&format!("time: {difference:?}"))
}
function silly_loop(n: int) {
const start_time = new Date();
while (n--) {
}
return (new Date() - start_time)
}
用 elisp,rust,deno 执行 (silly_loop 50000000) 的时间对比
语言 | 执行时间 |
---|---|
interpreted elisp | 2950.89 ms |
byte-compiled elisp | 544.47 ms |
native-compiled elisp | 320.82 ms |
rust(emacs rust dynamic modules) | 67.15 ms |
TypeScript(deno-bridge) | 43.06 ms |
是, 基本上是 Elisp 的几十倍。
v8对循环会做动态优化,循环的前几次和后面的运行速度会不一样,如果循环内部什么都不做的话,这样的时间没有太大意义。
期待一个 killer app 啊
是的。还要加上数据交换的开销
初步尝试使用 deno-bridge 写插件,使用起来无顺畅。猫哥强无敌。
deno-bridge-jieba : GitHub - ginqi7/deno-bridge-jieba: deno-bridge-jieba
因为自己常常会把网络上的文章,用org mode 保存下来。因此,对中文文档的查阅、编辑是一个常规操作。
需要一个适当的中文分词方案,能够快速的forward-word, bacward-word 。之前曾使用过start-process-shell-command + python + jieba 的方案。只不过,其中emacs 代码里充满了对 shell output 解析,比较混乱。
deno-bridge 可以对jieba 分词这个功能进行重新实现。使用 deno-jieba 把分词的功能全部交由ts 代码,emacs lisp 仅仅负责交互。
deno-bridge-jieba 功能还不稳定,但用deno-bridge 实现的过程确实比较舒服,日常使用的过程中再慢慢完善。
已有的其他emacs-jieba 项目:GitHub - cireu/jieba.el: 在Emacs中使用jieba中文分词