[Build] Significantly Improve Build Times Using Unity Builds#4948
Merged
[Build] Significantly Improve Build Times Using Unity Builds#4948
Conversation
KimLS
approved these changes
Jun 22, 2025
307c1d1 to
2d750c1
Compare
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
🚀 Using a 16c/32t Intel chip - it has dropped non-cached, cold start build times by a whole minute. Reduces memory footprint and speeds up developer iteration.
This PR introduces unity builds into our project for Perl / Lua Bindings and Commands. The reason for this is to strike a sweet spot between frontend and backend compilation times parsing giant headers recursively for many different cpp files. It causes giant memory spikes and is extremely slow to do for many individual files. Many of these files introduced into these unity build units all need similar headers so they get "batched" together, reducing translation units, compilation time, less header parsing. Below details more of the nitty gritty and testing done to achieve a balance in batch #'s below -
This is based off of efforts to cleanup the codebase, modernize and make it more efficient.
I have a branch called
build-analyzethat runs a trace of what takes up all of the build time (example here http://drone.akkadius.com/EQEmu/Server/18259/1/2)This has brought to light inefficiencies of our code base and with that some measurable things that we can do to substantially cut down on problem areas.
There are other things we are addressing through other strategies in other PRs.
⏱️ Build Time Improvements
Using a 16c/32t Intel chip - it has dropped non-cached, cold start build times by a whole minute.
💾 Massive Memory Reduction
🧠 Developer Productivity Boost
Type of change
Testing
Tested compiling, running basic processes etc.
Ran many tests using different variations of unity build batch size params --
Linux (16c/32t Core Intel - 5Ghz)
Master
rm -rf ~/.ccache/* && ninja clean && time ninja -j$(expr $(nproc) - 2)
2m22.041s
Unity Build Batch Size (Perl) 4 / (Lua) 4 / (GM Commands) 8
1m47.413s
Unity Build Batch Size (Perl) 8 / (Lua) 8 / (GM Commands) 16
1m39.186s
Unity Build Batch Size (Perl) 16 / (Lua) 16 / (GM Commands) 32
1m39.686s
1m41.284s
Unity Build Batch Size (Perl) 16 / (Lua) 16 / (GM Commands) 64
1m40.933s
1m40.275s
Unity Build Batch Size (Perl) 8 / (Lua) 8 / (GM Commands) 32
1m35.557s
1m36.772s
Incremental Build (Editing eqemu_logsys.h) (Perl) 8 / (Lua) 8 / (GM Commands) 32
0m15.853s
0m16.900s
0m17.065s
Checklist