tldr-node-client icon indicating copy to clipboard operation
tldr-node-client copied to clipboard

Way faster without spinner

Open BuonOmo opened this issue 10 months ago • 6 comments

Description

I'm creating a repository to benchmark various tldr implementation (https://github.com/buonomo/tldr-benchmarks). RN, the node client is in the slow category and I'm not even running the benchmark for it as time for a tldr --update was >2mn. I've investigated a bit with 0x and some googling, and it seems like the spinner is actually the cause. When removing it I end up having a 5s update time, which is the time for an average client. So this PR is just removing this slow timer.

Checklist

Please review this checklist before submitting a pull request.

  • [x] Code compiles correctly
  • [ ] Created tests, if possible
  • [x] All tests passing (npm run test:all)
  • [ ] Extended the README / documentation, if necessary

BuonOmo avatar Feb 17 '25 14:02 BuonOmo

I see that the latest version of ora is 8.2.0. Would you be able to run your benchmarks using the latest major version and see if there's any improvement?

agnivade avatar Feb 17 '25 14:02 agnivade

I see that the latest version of ora is 8.2.0. Would you be able to run your benchmarks using the latest major version and see if there's any improvement?

I already tried ora 8.2 and yocto-spinner (supposedly fast and tiny according to ora's doc). Both were slow. I also tried yocto-spinner with an interval of 800ms instead of 80. TBH I don't understand how this can be so slow. I've looked at yocto's code, it is just an interval and some printing...

BuonOmo avatar Feb 17 '25 15:02 BuonOmo

Thanks. Very interesting. I hope it's not blocking the event loop in any way. Because at the end of the update, we have an index rebuilding phase which is purely CPU work. So if the spinner is blocking a lot of that, then it gets slow. But even then, it shouldn't be so much slow as you are reporting.

agnivade avatar Feb 17 '25 16:02 agnivade

Thanks. Very interesting. I hope it's not blocking the event loop in any way. Because at the end of the update, we have an index rebuilding phase which is purely CPU work. So if the spinner is blocking a lot of that, then it gets slow. But even then, it shouldn't be so much slow as you are reporting.

I experienced the same issue when updating the cache (last time I used the node client on Windows, currently I use the Rust one) where cache update would take a lot of time >2 minutes even on fairly recent hardware that I have. It never occurred to me that the spinner could be the main reason for it to be very slow.

kbdharun avatar Feb 17 '25 16:02 kbdharun

@agnivade the was actually happening during the index rebuild phase!

BuonOmo avatar Feb 17 '25 16:02 BuonOmo

Right. I think the spinner is not meant to be used when some CPU intensive work which does not yield to the event loop is running. Let's remove it.

agnivade avatar Feb 18 '25 04:02 agnivade

@sebastiaanspeck I've seen you finally rebased yourself. Shall I let you handle the PR from now on?

BuonOmo avatar Nov 18 '25 23:11 BuonOmo

@sebastiaanspeck I've seen you finally rebased yourself. Shall I let you handle the PR from now on?

Feel free to take the PR back if you believe any changes are still needed.

sebastiaanspeck avatar Nov 19 '25 05:11 sebastiaanspeck

Well I saw that tests were failing, but looking at the test it seems completely unrelated, isn't it? Besides that, I have nothing in mind

BuonOmo avatar Nov 19 '25 07:11 BuonOmo

Well I saw that tests were failing, but looking at the test it seems completely unrelated, isn't it? Besides that, I have nothing in mind

Yeah, I see #517 failed as well yesterday. In #517 he thought it was related to Cloudflare issues yesterday.

sebastiaanspeck avatar Nov 19 '25 09:11 sebastiaanspeck

Could you ping me whenever you publish the new version, so I can update the benchmark :)

BuonOmo avatar Nov 26 '25 13:11 BuonOmo