Skip to content
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.

Sign up for GitHub

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

Jump to bottom

checkout@v2 fetch download speed sometimes slower than v1 #119

Closed
gregwym opened this issue Dec 20, 2019 · 4 comments
Closed

checkout@v2 fetch download speed sometimes slower than v1 #119

gregwym opened this issue Dec 20, 2019 · 4 comments

Comments

@gregwym
Copy link

gregwym commented Dec 20, 2019 •
edited
Loading

with checkout@v2 it indeed saves a lot of bandwidth but seems much slower on the download speed. Please see the comparison bellow. Is it because GitHub has to do the compression on the fly when fetching with --depth=1?

V1
image

V2
image

Initially reported at #22 (comment)
@gregwym
Copy link
Author

gregwym commented Dec 23, 2019

Another round of test, even much slower. It also spend quite some time on the "Updating files" phase.

image

@ericsciple
Copy link
Contributor

Curious about the overall time difference? The ... menu has a Show timestamps menu item. Guessing from the screenshots around 7s vs 20s.

It looks like in this case, HEAD has large files?

@ericsciple ericsciple changed the title checkout@v2 fetch download speed is slower than v1. checkout@v2 fetch download speed sometimes slower than v1 Jan 9, 2020
@ericsciple
Copy link
Contributor

Changed the title since it depends on the factors. V2 is optimized for scenarios such as gb of history, where only downloading HEAD saves many minutes.

@ericsciple
Copy link
Contributor

Closing since this is a tradeoff and the difference is seconds not minutes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@gregwym @ericsciple