今天突然发现,没有用 native comp 似乎反而流畅了很多

之前一直尝鲜 native comp,最初的时候似乎确实能感觉到一些优化,尤其是以前用 lsp mode。

今天升级 Emacs 29,突然想不开 Native Comp 试一下,突然发现明显流畅了很多,也不知道到底是为啥,几个明显的感觉:

  1. 之前 ivy-rich 十分耗时,切 buffer 的时候总是会卡一下
  2. 有了 lsp-bridge 之后,完全抛弃 lsp mode,似乎也不需要当初的 Native Comp 了
  3. Native Comp 在初次安装完 Emacs 需要大量的时间编译,这次装完直接就能用了

对了,平台是 macOS Intel CPU,使用 emacs-plus@29

碰到类似情况的道友可以尝试关闭 Native Comp,说不定有不一样的提升

2 个赞

你尝试 blink-search 以后, 就可以知道在超多文件时, 比 ivy 还快的性能。

哈哈,猫大你的大部分插件我都有尝试使用,有一些抵不过习惯的力量,忙起来就会荒弃,回到原来的习惯。

blink search 我再掏出来适应一下

反正开了native compile后magit是流畅了很多

用了几天,还真是,去掉 navtive compile 之后,magit 明显都需要卡一会才有反应

@manateelazycat 有没有 magit-bridge 的想法 XD

我开发了eaf git,操作模式有点像傻瓜化的 lazy git,功能没有magit强大,但是我每天都在用。

从我的理解看,magit主要的性能瓶颈在于log分析和搜索,这一块可以借鉴blink-search的原理,外部进程做超大log分析,emacs只绘制虚拟列表(只绘制屏幕内几十条log状态),eaf git就是这样设计的,打开一百万条commit不卡。

1 个赞

论坛本来就是信息分享的地方,例如看到懒猫上面的介绍,我暂时也不会去用他的eaf git,毕竟magit用了好多年,可保不齐那天我对magit不爽了,至少知道还有一个备选项。你在这里做纯粹的人身攻击又有什么意义呢,欢迎你也开发出各种各样的插件,然后在各种帖子里宣传,我不介意这样的广告。

6 个赞

不等于到处打广告

懒猫大佬应该都发过帖子,不用在每个帖子下都回复你应该也会知道

我介意

个人想法:我会根据标题会对下面的回复有个预期,但是看着看着有个偏离的广告还是挺打断思路的,例如 magit 性能问题,我就想在下面找怎么搞定它的性能而不是换掉它(换掉它可以是单独的帖子,当然懒猫大佬开发的 lsp-bridge 还是非常好用的!

4 个赞

我觉得应该多到 Reddit,hacker’s news 宣传,从我在 IRC 的体验来说在中文社区以外宣传得还不够,不上 melpa 导致很多 emacs 用户都不知道有这些工具

我直说了吧,用外部程序代理处理数据是当前版本最优解了,其他的方法你也问不出来的

我也不怕你们说我偏袒,主题本来就有 lsp-bridge,关于 git 相关插件的问题还是题主主动 At 的,我不认为有不妥的地方

4 个赞

是的,magit其他的操作慢一点我都可以接受,唯一无法忍受的就是log界面。

虽然我看到帖子隐藏了, 但是我还是截图给大家看一下。

你我互相不认识, 没必要和你争论, 但是我要表明我自己的态度:

  1. 题主说native comp的问题, 我只想表明, Emacs的慢在于单线程和GC, 我已经在多个主题说明, 也做了大量的实践, 这也侧面证明 native comp 在很多地方并不有效, 虽然对 magit 有帮助, 但是 magit 有 log 的时候依然很卡, 我 24 天前说了这个观点以后就没吭声了, 即使楼主说 blink search 不适应, 我也没吭声
  2. 昨天楼主 @ 我说 magit-blink 的想法有没有, 我只是从 eaf git 的实践说明了, magit 的慢在于Emacs本身, 大家吐槽 magit 慢主要在于 log 太长了卡, 其他挺好用的, 我只说 eaf git 确实解决了性能问题, 但是我也同时说明了, eaf git 功能不如 magit 强大, 我自己用够用, 但是我从来没有强迫大家用, 也没有说功能上 eaf git 比 magit 强大, 这是客观事实
  3. 你们不要 @ 我, 我根本不会主动去帖子说我的东西, 我在自己项目的帖子已经说的足够多了, @ 我, 我说一下自己的观点不行吗?

如果你不喜欢我的回复, 你完全可以屏蔽我, 但是你的用词我真的不知道该说什么好, 我自己写了很多插件, 分享出来, 就是你说的那样的吗? 你不觉得你这样用词很侮辱人吗?

15 个赞

magit 完全是可以像 blink-search 那样的原理来解决 log 界面的性能, 这样既可以保持 magit 的强大, 又可以靠外部进程解决 magit log 性能慢的问题。

我觉得他有点奇怪,开源本身最重要的就是自己用的爽,都是因为不满意现有的工具才走上这条路的,从同理心出发,希望给遇到同样问题的一点建议和启发,少走弯路,很简单的逻辑。他似乎很习惯于自我贬低,同时也要阴暗的揣测别人才能逻辑自洽。批评好坏要落到实处,虚空打靶就很很没意思了。

3 个赞

我觉得吧,你看不惯可以选择屏蔽,没必要用上「全宇宙」「恶心」「强奸」这样的字眼去攻击他人

1 个赞

算了, 没必要。

我这段时间很忙, 平常论坛@我, 我只能快速的回复一下, 没有额外的想法,希望我的经验可以帮助他人, 晚上研究社区补丁的时候, 看了一下论坛, 虽然我和他不相识, 但是看到这么用词, 心里还是咯噔一下。

古人说, 勿行大善, 原来不理解了, 今天理解了。

11 个赞

最近也一直用 native comp,就是升级包 compile 之后第一次启动反而慢,但之后都正常。

我的想法是,除非常用的插件稳定,否则好像没必要开。

(被隐藏的帖子的发帖人不知道哪里来的这么大的恶意,在我看来懒猫无私为社区贡献了这么多优秀的插件,他提及自己的解决方案再正常不过了,退一万步说请问其中涉及到任何商业行为了吗?懒猫的言行没有问题,反而是这些人肆意践踏他人的善意,恶语伤人六月寒。)

4 个赞

emacs社区本来就没几个人,大家都友善一点,网上的帖子和回复那么多,你不感兴趣的忽略就好了,只要不是整页刷屏我觉得问题就不大。 话说懒猫大佬的包能上melpa的话会更方便,也会有更多人愿意尝试,自己管理包和配置还是有些麻烦

对于出言不逊的人,无论其动机为何,只要没有实质性破坏能力,就当作生物多样性好了。正常人做正常事即可,不想太多,更不必挂心上。

尴尬了,没想到我一个问题引起这么大矛盾, @manateelazycat 是在是抱歉啊。

作为发帖人,我必须也得说明一下我的态度,本来也是我主动 at 懒猫,主动提出开发一个类 magit 的应用,懒猫和我说有一个 eaf git,这百分百切合了我的问题,我是十分感谢懒猫的回复的,而且我在看到 eaf git 的回帖的之前,是没印象有这么个插件的。

个人也觉得,这么过激的言论实在是没必要,除了宣泄自己的情绪,看不到任何好处,并且还破坏了其他人的心情