Performance of opening a monorepo is very slow vs GitHub Codespaces

[ghuntley]

Objective

Open https://github.com/NixOS/nixpkgs in Gitpod and at the same time open https://github.com/NixOS/nixpkgs in GitHub codespaces.

GitHub Codepaces loads in <10 seconds.

Gitpod loads in > 90 seconds.

GitHub Codespaces provides the user with a detailed overview and logs of what it is doing.

Gitpod provides a bouncing logo and "initialising context"

[ghuntley]

Some extra perf stuff:

Gitpod

$ git branch test
$ time git checkout test
Switched to branch 'test'

real    0m0.822s
user    0m0.568s
sys     0m0.383s

GitHub Codespaces

$ git branch test
$ time git checkout test
Switched to branch 'test'

real    0m0.158s
user    0m0.083s
sys     0m0.106s

[geropl]

Hey @ghuntley! 👋
Regarding the performance comparison: That's something we're constantly monitoring and improving. I'm in favor of closing the issue as it's not actionable, and already covered by a constant process. Fine with you?

[ghuntley]

Not really. Strange that this was right away closed.

There’s three actionable things here:

• The Gitpod loading screen does not provide enough context to user what is happening. Codespaces provides insights and reassurances that the loading is well still loading. Codespaces has a progress indicator essentially.
• Codespaces loads 80 seconds faster.
• Codespaces switches git branches 700ms faster.

[aledbf]

Codespaces loads 80 seconds faster.
Codespaces switches git branches 700ms faster.

@ghuntley thank you for bringing this to our attention.

The difference is related to the git clone command between the two platforms.

In Gitpod, you can find we use git clone --no-single-branch --depth 1 while in Codespaces, they are more specific using git clone --branch master --depth 1 (you can find the command in /workspaces/.codespaces/.persistedshare/creation.log)

Here is a screenshot showing the times you observe:

The flag --no-single-branch was introduced in #6464 in an attempt to use --filter=blob:none (which didn't make it).

I will open a PR to revisit the use of the flag --no-single-branch

[ghuntley]

Legend as always Alejandro

[david-bakin]

Suppose that gitpod changes back to not having --no-single-branch - then in that case if you wanted to checkout a different branch would you have to git pull something? Would you actually have to do something to get all the tags (i.e., including other branch names)? If so I like the current behavior instead. If it is changed I'd like to suggest adding a property to .gitpod.yml to control this behavior so it can be selectable per-repo. (I also don't understand the implications of --depth 1 w.r.t. these questions but I'll look for that information elsewhere.)

[aledbf]

I also don't understand the implications of --depth 1

When you open a workspace, Gitpod only checks the last commit to open the UI as soon as possible.

From https://git-scm.com/docs/git-clone:

--depth
Create a shallow clone with a history truncated to the specified number of commits. Implies --single-branch unless --no-single->branch is given to fetch the histories near the tips of all branches. If you want to clone submodules shallowly, also pass --shallow-submodules.

Once the UI is ready (and the .gitpod.yaml file is processed), the rest of the repository is fetched in the background.

If so I like the current behavior instead.

You should see no changes without --no-single-branch once git fetch finishes.

[kylos101]

The Gitpod loading screen does not provide enough context to user what is happening. Codespaces provides insights and reassurances that the loading is well still loading. Codespaces has a progress indicator essentially.

GitHub Codespaces provides the user with a detailed overview and logs of what it is doing.

@jldec can you share if there are existing issues for ☝️ or would it make sense to track in new issues? I ask because @aledbf is addressing performance observations as part of #13053.

[david-bakin]

Once the UI is ready (and the .gitpod.yaml file is processed), the rest of the repository is fetched in the background.

Ah! That's the key.

[atduarte]

Resolved and published: https://www.gitpod.io/changelog#faster-startup-times-for-large-repositories