Skip to content

Conversation

@footballhead
Copy link
Collaborator

@footballhead footballhead commented Oct 28, 2025

Every time I changed a git branch or made a commit, it would take 1+ minute to build GFXR. This was caused by many large C++ files including a header file which contained the git SHA; every time the SHA changed, those files would need to be recompiled. Since they were large files, this took a long time.

Instead of consuming the SHA directly, hide it behind a function call and let the linker deal with it. This reduces the number of targets to recompile every time the git SHA changes. The only exception is version.rc which wants a string literal.

@footballhead footballhead changed the title Improve developer build times by hiding git SHA GFXR: Improve developer build times by hiding git SHA Oct 28, 2025
hysw
hysw previously approved these changes Oct 28, 2025
wangra-google
wangra-google previously approved these changes Oct 28, 2025
@wangra-google
Copy link
Collaborator

Thanks for making this change.
The only concern i have is that this is touching many files in the gfxr code which would make future integration more difficult?

@footballhead footballhead dismissed stale reviews from wangra-google and hysw via 12dc897 October 28, 2025 21:26
@footballhead
Copy link
Collaborator Author

footballhead commented Oct 28, 2025

Thanks for making this change. The only concern i have is that this is touching many files in the gfxr code which would make future integration more difficult?

I have the same concern. I was hoping that splitting target_link_libraries(foo project_version) out into a separate block could alleviate that. While I could try to reduce the number of lines of code changed, it comes at the cost of linking specificity. Unfortunately, being very specific in the build graph is one of the best ways of reducing the number of things recompiled.

The other option is that we remove the SHA altogether. That might be fewer lines of code and may build even faster by reducing the need to link as well.

Every time the git SHA changes (new commit, branch change, etc), it
would take 1+ minutes to build GFXR. This was caused by many large
C++ files including a header file which contained the SHA; every time
the SHA changed, those files would need to be recompiled. Since they
were large files, this ended up taking a long time.

Instead of consuming the SHA directly, hide it behind a function call
and let the linker deal with it. This reduces the number of targets to
recompile every time the git SHA changes. The only exception is
version.rc which wants a string literal.
@footballhead footballhead force-pushed the faster_incremental_git branch from 12dc897 to 5c1756e Compare October 30, 2025 20:24
@footballhead
Copy link
Collaborator Author

FWIW I found that my laptop was on the "balanced" power profile. If I increase Processor Power Management > Minimum Processor State > Plugged in to 100%, it takes 46s without this fix and 6s after.

My test:

# Build the layer once to generate a baseline
gradlew layer:assembleDebug -Parm64-v8a

# Generate a new SHA without code changes
git commit --allow-empty -m "test"

# Rebuild layer with only the SHA change
gradlew layer:assembleDebug -Parm64-v8a

@wangra-google
Copy link
Collaborator

FWIW I found that my laptop was on the "balanced" power profile. If I increase Processor Power Management > Minimum Processor State > Plugged in to 100%, it takes 46s without this fix and 6s after.

My test:

# Build the layer once to generate a baseline
gradlew layer:assembleDebug -Parm64-v8a

# Generate a new SHA without code changes
git commit --allow-empty -m "test"

# Rebuild layer with only the SHA change
gradlew layer:assembleDebug -Parm64-v8a

that is great, thanks for verifying the actual gain.

@footballhead
Copy link
Collaborator Author

I'm going to create a PR upstream to increase the impact of the fix as well as reduce the number of conflicts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants