search

manateelazycat / blink-search

In the blink of an eye, the search is complete
114 stars 15 forks source link

启动时会卡5秒，输入后会导致无法使用 #42

Closed heheda123123 closed 1 year ago

heheda123123 commented 1 year ago

第一次启动的时候会卡5秒，如果这个时候什么都不做，等5秒之后就能用了，但是如果尝试输入就会显示一句错误

or: Wrong type argument: blink-search-epc-manager, nil

image 在已经出现错误之后，再输入，blink-search不会发生任何变化，需要重新打开才能用，第二次就不会卡了 image

卡顿是必须的吗？

manateelazycat commented 1 year ago

应该是Windows本身启动进程太慢了， 你在配置文件中加入 (blink-search-start-process) 应该可以解决你的问题。

这个代码的意思是提前把 blink-search 的Python后端启动起来， 但是考虑到Windows本身的问题， 如果加到配置文件会导致Emacs启动要等5秒时间。

heheda123123 commented 1 year ago

用lsp-bridge也会遇到同样的问题，启动后端会导致界面卡5秒左右。
不能马上用没关系，但是能做到不卡界面不，就让python后端自己启动，启动好了再正常使用。

manateelazycat commented 1 year ago

我建议你emacs -Q对比测试下，避免你配置影响。

启动进程都是不卡界面的。

heheda123123 commented 1 year ago

这是现在的情况我录了个屏，猫哥看下 2023-06-29 13-18-10.zip

heheda123123 commented 1 year ago

这个是emacs -Q的情况下测试的，存在同样的问题，全程按着a没松手 2023-06-29 13-29-37.zip

manateelazycat commented 1 year ago

暂时不知道原因，我不用windows

heheda123123 commented 1 year ago

应该是Windows本身启动进程太慢了， 你在配置文件中加入 (blink-search-start-process) 应该可以解决你的问题。

这个代码的意思是提前把 blink-search 的Python后端启动起来， 但是考虑到Windows本身的问题， 如果加到配置文件会导致Emacs启动要等5秒时间。

是有点奇怪，配置都已经执行完可以输入了才开始卡，不是卡在配置加载的阶段
不是卡在 (blink-search-start-process)，测了下这行代码0.01s就执行完了 lsp-bridge也存在同样的情况，应该是架构的共性问题。

heheda123123 commented 1 year ago

另外还有个问题，就是补全的流畅程度，我开始以为在lsp-bridge上有点卡顿是因为我用windows的原因，但是试了下lsp-mode，补全很流畅。按理来说，lsp-bridge这种架构应该更流畅才对。

manateelazycat commented 1 year ago

我不知道Windows的问题， lsp-bridge在linux下， 要比 lsp-mode 和 eglot 流畅非常多。

heheda123123 commented 1 year ago

我把blink-search-start-process拆开执行，发现确实是start-process这句执行之后造成的卡顿 有点奇怪，这不是创建了一个异步的进程吗，难道是emacs的bug? 应该不大可能，因为卡顿是在start-process执行返回之后才出现，问题应该不在这里。

image

heheda123123 commented 1 year ago

我测了下python-bridge,在这几个函数加了类似这样的输出操作

python-bridge-epc-server-start
python-bridge-epc-server-sentinel
python-bridge-epc-server-accept
python-bridge-epc-process-available-input
python-bridge-epc-net-send
(python-bridge-epc-log (format-time-string "SEND] %Y-%m-%d %H:%M:%S" (current-time)))

然后执行下面三行代码

(add-to-list 'load-path "~/temp/python-bridge")

(setq python-bridge-epc-debug t)
(require 'python-bridge)

最后输出如下(去掉了空行)

start] 2023-07-02 15:39:32
sentinel] 2023-07-02 15:39:34
LSPBRIDGE-EPC-SERVER- SENTINEL: #<process PYTHON-BRIDGE EPC Server 2 <127.0.0.1:1550>> "open from 127.0.0.1"
accept] 2023-07-02 15:39:34
LSPBRIDGE-EPC-SERVER- >> Connection accept: #<process PYTHON-BRIDGE EPC Server 2 <127.0.0.1:1550>>
LSPBRIDGE-EPC-SERVER- >> Connection establish
INCOMING: [python-bridge-epc con 3] ["00003e(call 1 eval-in-emacs (\"(python-bridge--first-start '1551)\"))"]
RECV] 2023-07-02 15:39:34
<< RECV [(call 1 eval-in-emacs ("(python-bridge--first-start '1551)"))]
SIG CALL: (call (1 eval-in-emacs ("(python-bridge--first-start '1551)")))
>> Connection start: localhost:1551
>> Connection establish
SEND] 2023-07-02 15:39:36
>> SEND : ["00000f(return 1 nil)"]

可以看到几个时间的间隔 从start到sentinel隔了2秒，从recv到send隔了2秒。 卡顿了4秒貌似能对应上这里？ 这个时间间隔正常吗？ 而且前两秒之后，emacs和python中的的tcp进程都启动成功了，至少后2秒应该不涉及windows启动进程慢的问题把

manateelazycat commented 1 year ago

肯定不正常， 你Windows是不是有啥防杀毒软件？

heheda123123 commented 1 year ago

肯定不正常， 你Windows是不是有啥防杀毒软件？

只装了个关闭全部防护功能的火绒 image

heheda123123 commented 1 year ago

我在py中也插入了一些打印时间的代码，可以看到windows中py进程基本也是1秒内启动了， 第二个时间是在这行代码之后输出的

init_epc_client(int(args[0]))

image 这个里面就只是执行了一个socket.create_connection，我把epc弄到本地，测试了下，还真是这个socket.create_connection花了2秒 image image

意思是客户端发起connect到python-bridge-epc-server-sentinel开始执行花了2秒，这就有点奇怪了，本地connect不可能花这么多时间呀，是不是python-bridge在处理连接请求的时候某个地方可能阻塞了（比如发起了dns查询之类的？） 包括前面recv也是瞬间完成，但是从recv到send之间又隔了2秒 在emacs这边，从python-bridge-epc-server-start执行结束到开始执行python-bridge-epc-server-sentinel，还执行了哪些代码呢？可以再详细定位下哪一句代码造成的。感觉不大可能是make-network-process底层实现的问题把

heheda123123 commented 1 year ago

image 又测了下，从设置sentinel函数到触发sentinel函数花了2秒，看了下emacs关于sentinel的文档 https://www.gnu.org/software/emacs/manual/html_node/elisp/Sentinels.html 里面提到“哨兵仅在 Emacs 等待时运行（例如，等待终端输入、等待时间流逝、或者等待进程输出）”，是不是因为有什么代码在运行，导致sentinel函数得不到运行。 但是我测了下，下面三个位置的执行时间都是一样的，

python-bridge-epc-server-start 开始执行时
执行了apply 'start-process之后
python服务端发起connect之前

我看了下python-bridge，如果只是require的话，好像只会执行这一个函数

(unless python-bridge-is-starting
  (python-bridge-start-process))
heheda123123 commented 1 year ago

image 这样看来，应该是emacs内部windows实现的问题了，从接收到网络请求连接到分发执行sentinel函数会存在延迟

晚点我再写个make-network-process的demo确认下最简化的代码是否有这个情况

heheda123123 commented 1 year ago

但是简单的demo看起来又没有问题，玄学 image

heheda123123 commented 1 year ago

咦，论坛上有老哥提了下，他也在windows上用emacs跑lsp-bridge，但是没卡顿的情况 image lsp-bridge还会受什么影响吗？比如环境变量？

heheda123123 commented 1 year ago

这是执行(python-bridge-start-process) 时 profiler的结果 难道是启动异步进程后，python python_bridge.py 把cpu占满了，导致卡顿的？但是这是另一个进程，和emacs没啥关系把 image

对了，如果猫哥实在不关心这个问题，我就不在这个issue发了

manateelazycat commented 1 year ago

我没环境

heheda123123 commented 1 year ago

我没环境

嗯，主要是我觉得猫哥熟悉emacs和python-bridge，说不定只是看我上面发的内容就直接知道问题在哪里了（：

heheda123123 commented 1 year ago

猫哥在吗，好像发现问题了，在执行 (python-bridge-start-process) 的过程中，我抓包看了下，存在tcp端口reused的情况。感觉可能是哪个地方创建服务器，传递的端口出错了 image image

heheda123123 commented 1 year ago

问题解决了，是emacs内部dns解析的问题，把localhost全部换成127.0.0.1之后一点也不卡了 猫哥把lsp-bridge blink-search都改一下把。不容易哇，终于能体验快速的lsp-bridge 了 image https://emacs-china.org/t/emacs-windows/24866/13

heheda123123 commented 1 year ago

这个原因好像是因为现在win上很多都把localhost给注释了，非要绕一圈到dns去查询 所以本地连接最好都写127.0.0.1 windows上经常遇到这个问题 image

manateelazycat commented 1 year ago

https://github.com/manateelazycat/lsp-bridge/commit/25be1a28fe6ca7dc91547c47d97c0558702fd41c

https://github.com/manateelazycat/blink-search/commit/f2d9229c59f294b052d46a958f965d757aeeefea

https://github.com/emacs-eaf/emacs-application-framework/commit/09be8b3807bc427962b1daf5af5889495d7d0fd9

https://github.com/manateelazycat/python-bridge/commit/76fcd6cc79ee740bd6a8ed5097436987d5eb9052

这四个项目都更新了， 感谢反馈， 为你锲而不舍的精神点赞👍