Annoying delay at each run
zeenix opened this issue · comments
Describe the bug
Each time I run the CLI, there is a very noticeable (almost 1sec) delay at the beginning. Even when I just want to see the help:
❯ time gitmoji --help
...
real 0m0.980s
user 0m1.189s
sys 0m0.148sOn my rather high-end machine, that's quite lot and gets annoying super fast.
Reproduction
time gitmoji --help
System Info
System:
OS: Linux 6.2 Fedora Linux 38 (Workstation Edition)
CPU: (16) x64 AMD Ryzen 7 4800H with Radeon Graphics
Memory: 46.31 GB / 62.21 GB
Container: Yes
Shell: 5.2.15 - /bin/bash
Binaries:
Node: 18.15.0 - /usr/bin/node
npm: 9.5.0 - /usr/bin/npmValidations
- Follow our Code of Conduct
- Read the Contributing Guide.
- Check that there isn't already an issue that reports the same bug to avoid creating duplicates.
- Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
- The provided reproduction is a minimal reproducible of the bug.
Hey!
Not sure why it takes so much time on your machine, just did a quick test on mine and is half of that time.
CLIs built with Node.js are not that good in performance compared to other languages, but I would be happy to review any PRs that improve the performance of the cli!
Would you like to take a stab?
Would you like to take a stab?
I have never coded Node and have very limited and outdated JS experience so unfortunately I won't be able to help with code. I'm a Rust guy. :)
Not sure if this helps but I straced gitmoji --help. Seems like a huge amount of syscalls being made by various components but maybe that's just normal in the nodejs world. 🤷
If there is any other information I can collect for you, please do let me know and I'll try my best.
oh and just FYI, this makes git rebase extremely slow. I'm guessing it's because the hook is run for every commit.
I so wanted emojis in commits, I spent most of my weekend creating Rust version of the CLI: https://github.com/zeenix/gimoji . 😆 It relies on your emoji DB and API so not really a competitor at all. Just a different implementation that's faster and slightly different approach. 👍
Awesome!!
Thanks for doing that, I'll close this issue then 😊
Have a great day
This issue is still valid though unless you intend to drop your cli for mine.
Perhaps you can add a sentence in readme like this:
"If gitmoji is too slow on your machine, consider using [gimoji]."
So that others bumping into this issue know that there's a way out.
Hey!
I believe the issue search is still available for everyone and by searching for "delay", "slow" you will be able to find this issue!
I'm not planning to drop gitmoji-cli at the moment, I will reopen another issue with a better description, details and insights to see if anyone's up for contributing into it
Best of luck with your project! 😊
I believe the issue search is still available for everyone and by searching for "delay", "slow" you will be able to find this issue!
That's a lot to ask/expect from users. Most people will just give up on the whole idea after trying it out and facing this issue, let alone search in closed issues (Github be default doesn't even show you results in closed issues).
At the end of the day, we both just want everyone to add emojis to their commits, regardless of which software they use to make it happen. A very poor user experience from the only CLI recommended by gitmoji project, will not help there at all.
I'm not planning to drop gitmoji-cli at the moment,
I understand and just to be clear, I didn't mean to suggest you should.
I will reopen another issue with a better description, details and insights to see if anyone's up for contributing into it
I'm not sure I follow this. Are you asking me to open an issue? 🤔
That's a lot to ask/expect from users. Most people will just give up on the whole idea after trying it out and facing this issue, let alone search in closed issues (Github be default doesn't even show you results in closed issues).
The issue with this approach is that you're not the only one who built an alternative client for gitmoji. Therefore if I add your project I might get a ton of other requests and I don't want to convert the readme into an "ads board".
At the end of the day, we both just want everyone to add emojis to their commits, regardless of which software they use to make it happen. A very poor user experience from the only CLI recommended by gitmoji project, will not help there at all.
I don't think the experience is as bad as you think it is. It can be improved for sure but a lot of people have been using this tool for years now (which I freely maintain in my spare time), with no complaints over performance
Sure it's not the fastest cli, but as you saw I'm getting quite different performance results, so maybe part of the problem can be unrelated to the cli.
I'm not sure I follow this. Are you asking me to open an issue? 🤔
No, I will open another issue with a task format so anyone can pick it up and leave it open, linking to the one you originally opened for context.
I will do this on my side as I originally mentioned
That's a lot to ask/expect from users. Most people will just give up on the whole idea after trying it out and facing this issue, let alone search in closed issues (Github be default doesn't even show you results in closed issues).
The issue with this approach is that you're not the only one who built an alternative client for gitmoji. Therefore if I add your project I might get a ton of other requests and I don't want to convert the readme into an "ads board".
Why do you think everyone will be building alternatives? I would definitely not have built one if it wasn't for this issue. Have you received any other such requests?
Anyway, your project, your rules.
I don't think the experience is as bad as you think it is.
I don't think it's as subjective as you want to believe. :) As I explained the issue is worse than I originally thought.
It can be improved for sure but a lot of people have been using this tool for years now (which I freely maintain in my spare time), with no complaints over performance
- So nobody had complained yet so you ignore the first report despite sufficient evidence provided that this is a significant issue? How do you know many people didn't just stop using your tool because of this instead of reporting it?
- I'm not getting paid either for this. :)
I'm not sure I follow this. Are you asking me to open an issue? thinking
No, I will open another issue with a task format so anyone can pick it up and leave it open, linking to the one you originally opened for context.
Ah ok. So you'll have an open issue for this. That's good.
In any case, I'm unsubscribing now. I said what I had to say.
So nobody had complained yet so you ignore the first report despite sufficient evidence provided that this is a significant issue? How do you know many people didn't just stop using your tool because of this instead of reporting it?
I'm not ignoring anything, again you're just assuming things, I just said I will create a separate issue with the proper context to see if someone is willing to help on it, given that I'm lacking the time to investigate the issue but looks like you missed my point.
I'm not getting paid either for this. :)
Sure but I'm not demanding anything to you either without providing any solution itself, as you're doing with me.
Probably you'll not end up reading this as you unsubscribed but I would suggest you rethinking the way you communicate and give feedback in OSS. Your tone sounds very demanding and rude to me, taking into account the context where we are (free open source software).
In any case, I'm unsubscribing now. I said what I had to say.
Nothing else to say then from my side, given that you don't have interest anymore in the topic I'll lock this issue and block you on GitHub to avoid dealing with toxic attitudes around my projects!
Have a great day