-
-
Notifications
You must be signed in to change notification settings - Fork 593
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v0.22.0 => increased app startup time #1436
Comments
That’s an Intretesting observation. Gonna look into this |
How did you make this exact measurement? |
Answer: I quickly scripted the following and I ran it with both versions and averaged them out:
Now, your question above prompted me to rerun my script on a fresh clone of gitui's own repo (with its more than 1700 commits), and this time I did get satisfactory results:
Update, I just redid the test on my own repo (fresh clone) and now I get similar satisfactory results to gitui's repo. so... Conclusion: not sure what is the problem with my older perso repo, but it looks like a fresh clone fixes the issue in my case. |
Update: the issue appears to be reproducible (and caused by the presence of a python .virtualenv directory) In the code block below, we can see that:
I hope this sheds some light on the issue. |
can you do me a favour and compare this in a debug build and the
the log on Mac can be found: ~/Library/Caches/gitui/gitui.log my theory is that if that's the case I assume the following commit is the offender: 216fad3 |
if we can validate that's the culprit we can fix it by making the waiting for the branches info async and have our fast(er) startup times again :) |
@alexmaco maybe you wanna clean that up? :) |
Hum, I am no Rust programmer, but building (as per) [master:b495425], and then running the resulting binary with
Does this help? |
no that is not a debug build, you can use |
Here are 2 trials:
BTW: did you manage to reproduce the issue on your side?
|
I am also getting consistent delay (1s - 3s) in startup. My work repository also have >2k commits. Although I didn't get chance to fully debug the behaviour. |
1s is super long. Can you build with timing like I mentioned above and share the log to figure out where the culprit lies? |
Sure. I'll paste the logs once done. |
@MartinVincent can you do your checks again with current master (3fee481) and check if
|
ok, so I did:
then :
then :
|
ok wow 600ms inside the appstart sequense. this is crazy. |
Approx 40000 files in .virtualenv:
and make debug for 8cdb023:
|
ok theory confirmed, its the file watcher initialisation - holy moly is that slow. |
it (following a make install) looks very good, in fact even faster than 0.21.0 :) according to my simple tests! Thx!
|
closed via bbcadcb |
new argument `polling` allows to force watcher to use polling instead of file system events. this should address the issue in gitui-org#1436 and maybe even gitui-org#1437
Hi @extrawurst,
First, thanks for this great piece of software, it truly is the best of the CLI Git clients!
Just want to make an observation regarding the 0.22 release: I really appreciate the update with the great new features (yes! (#1371)), but I noticed that there is now a significant delay on startup for relatively small repos (1500 Commits):
0,094
(v0.21) up to0,746
(v0.22).Is that expected? (ie: the price to pay for the new features)
Thx!
The text was updated successfully, but these errors were encountered: