-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Replace 'show-ref' command with 'branch' and 'tag' #14201
Replace 'show-ref' command with 'branch' and 'tag' #14201
Conversation
Codecov Report
@@ Coverage Diff @@
## master #14201 +/- ##
==========================================
+ Coverage 42.00% 42.02% +0.02%
==========================================
Files 733 733
Lines 78713 78736 +23
==========================================
+ Hits 33061 33092 +31
+ Misses 40218 40215 -3
+ Partials 5434 5429 -5
Continue to review full report at Codecov.
|
return branchNames, nil | ||
} | ||
if err != nil { | ||
// This shouldn't happen... but we'll tolerate it for the sake of peace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean the old comment is wrong, right? The position is where the return value is. So i moved it here which makes more sense to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or maybe we should just delete this comment. The old position just does not seem right to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should still be the original position. It means err == io.EOF
in fact is not an err. At a normal situation, reader shouldn't return that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lunny has the correct interpretation. Please revert
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Am I misunderstanding this? The err == io.EOF
seems to be the only way to break out the loop normally, but "at a normal situation, reader shouldn't return that"? How should we break out the loop, though
@skyline75489 can you add unit tests? Benchmark tests would be nice too but I'm ok without them :) |
I've not yet tested this enough. On my mac the performance is not stable. I think it's because some kind of disk caching by macOS. Overall show-ref is still slower since it fetches all the hashes that end up being unused. i will test this on Windows later. My main concern is that i don't really know if the change is completely harmless. Is there any situation that show-ref handles but branch/tag does not. |
So this is what I got from my Windows machine with SSD:
This is on the same machine but with a 5400 rpm hard disk:
The performance seem to be CPU-bounded rather than IO-bounded. The ~20s results was on my old MBP2015. |
@zeripath ping ;) |
FYI, the gogit variant performs basically the same as ‘show-ref’. We are not using gogit by default, though. |
@6543 So i was trying this with a smaller repo (200 branches) and found that the perf diff is not very obvious. I guess the perf diff will only emerge with a very large amount of branches/objects. I don’t I can easily add a benchmark test until I can find a way to mock a very large repo. By the way the PyTorch repo really reveals some internal issues in gitea. Using large repos like PyTorch & TensorFlow is a true test for gitea to see if it’s scalable enough. |
How about to keep the function |
@lunny That’s was my initial implementation. Then I found that |
If we are talking about performance you must tell us what version of git you are using. Also I wonder if you have a poorly or unpacked repo. That could explain the huge difference. |
git branch and git show-ref do different things. I suspect that you'll be missing other branches. |
On windows I’m using I’m not sure what you mean by ‘poorly’ or ‘unpacked’. Here’s how I get the PyTorch repo:
Be warned that the clone & push steps take a considerable amount of time if you wanna try this yourself. As for the behavior of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The referenced issue specifically references v1.13 - please ensure that this is actually needed on master since the no-go-git PR was merged.
#14180 (comment) appears to indicate that show-ref is not the problem. |
@zeripath I tested this on a Linux machine and found that the performance difference between EDIT: Seems that # of CPU cores matter a lot. My old MBP has only 2C4T. And |
I'll close this for now since I can not provide a definitive conclusion that this works for every repo & machine. Let's focus on whatever hot paths that causes #14180 . |
Supports #14180.
I'm no expert at git but I found that
git show-ref
is much slower thangit branch
andgit tag
. With this PR, the loading time of the PyTorch repo homepage drops from ~20s to 5s.I also added the reverse logic for
GetTags
which somehow left out in #13673. The reverse logic exists in the gogit variant.