search

stevearc / conform.nvim

Lightweight yet powerful formatter plugin for Neovim
MIT License
3.12k stars 163 forks source link

perf: use `uv.spawn` instead of `jobstart` for better child process IO performance #191

Closed linrongbin16 closed 11 months ago

linrongbin16 commented 11 months ago

Hi, I noticed that the internal implementation of running a formatter command is using the API jobstart. It's also the previous implementation of my plugin linrongbin16/gitlinker.nvim, forked from ruifm/gitlinker.nvim.

I recently added a modified version of vim.system (API from latest Neovim nightly), which is a user friendly version of uv.spawn (e.g. vim.loop.spawn introduced in Neovim 0.5+), it has a super good performance on child process IO.

Even when we run a command line and wait for its response (e.g. sync), uv.spawn still has the super good performance, compared with jobstart.

I'm so lazy so I cannot provide any benchmark data for you, but I feels like my gitlinker.nvim speed up from about 0.8 ~ 1.2 seconds to less than 0.2 seconds. Inside it will run about 2 ~ 5 git commands in a git repo.

If you have any interest, please see:

  1. replace old jobstart API to spawn here: https://github.com/linrongbin16/gitlinker.nvim/commit/35aebb7f4f8d30b7863742864a93cbe0224e8975#diff-78b3d3e35fb07653940e1e29882d42b81f9e83663772c3786617e682cccf29a7L39
  2. implement the spawn here: https://github.com/linrongbin16/gitlinker.nvim/commit/35aebb7f4f8d30b7863742864a93cbe0224e8975#diff-5b092e9c8aa7a8be4cc1086ddd1101289567012f06c35faa670fbe2578472ae2R229

I could try to submit a PR to improve the plugin performance.

stevearc commented 11 months ago

I considered doing this a while ago, but looking at the amount of code that would be required to replace jobstart with spawn...it's not great. Adding that much code is a noticeable maintenance burden, and I don't want to do it without good reason. Given that I haven't had any complaints about performance, and haven't noticed any performance problems myself (other than the cases where the formatter itself is slow), I don't think there's much upside.

Plus, I get the feeling that nvim 0.10 is fairly close to release. I would expect to see it come out some time in the next couple months. I'd prefer to just wait for that and use vim.system then.

lopi-py commented 2 months ago

@stevearc I'm having some performance issues, for example prettierd and black are taking about 250-600 ms and feels unacceptable, with vim.system its less than 200 ms. Would you accept a PR?

stevearc commented 2 months ago

@lopi-py sure! We'll have to do a major version bump to drop support for older nvim versions, but I think it's justified. If you put up an initial version I'll iterate on it with you to handle the deprecation gracefully.