fix: terrible git status performance in large repo

[33KK]

schedule_wrap floods the event loop with work that could've been done right away much faster here. massive improvement with my goofy git repo $HOME without a .gitignore

[cseickel]

Schedule.wrap is usually there for a very good reason. I'm afraid I can't evaluate whether schedule.wrap is actually required or not, see: #1606

[pynappo]

I believe there's no need for schedule_wrap here, because the jobs are just reading git output and putting it into the lines table. The only interaction with neovim here is if should_process errors to the console, but log.error properly vim.schedules logs to the console anyways. LGTM, pinging @cseickel.

[cseickel]

@pynappo I'll go ahead and merge this, but here are a few things to consider if bugs appear:

One reason this might have been set up this way could've been to not freeze neovim when the git work was slow. Maybe it was a bad solution to use schedule_wrap, but is there any other way to background this work?

There may have been some other reason that was not recorded in comments. Be on the lookout and I would suggest finding the PR where this code was merged for an explanation.

[33KK]

schedule_wrap doesn't background the work, it more or less just postpones it, while adding overhead. It runs on a single thread either way

[cseickel]

@33KK I think it's like a javascript await, where it just task switches which at least allows the app to remain responsive even while it is handling the long running job of reading the git response in little chunks. Not really backgrounding but a similar end result from a UX point of view. If that is why it was done, doing so in batches of 100 or 1K lines would have been a better way to handle it.

Now that I am reminded, I think that is how it was originally done but someone changed it along the way.

[miversen33]

vim.schedule takes a callable and adds it to the uv.loop queue to be processed "later" (where later is configured by neovim on loop startup. I don't recall the configuration choices available or what is used by neovim).

I believe the default behavior is "whenever is convenient".

vim.schedule_wrap "prepares" a function for this, but importantly doesn't add it to the queue. schedule_wrap returns a callable that you call later to add the provided function to queue.

As an example, these 2 should be the same

local scheduled_function = function() vim.schedule(function() print("hello world!") end) end
-- We have created a function that when called will schedule our print statement
-- Note, nothing has happened yet, If we were to _not_ run the next line, we would never see our message
-- as it was never scheduled
scheduled_function()
-- Now we ran it, and we should see our message print to the console

And

local scheduled_function = vim.schedule_wrap(function() print("hello world!") end)
-- At this point, nothing has happened, we have simply received a function that will schedule our function later
scheduled_function()
-- Now we ran it, and we should see our message print to the console

Probably not important but figured I would explain anyway :)