Xcode 16 Builds very slowly

Describe the bug

Initial builds with Xcode 16 are significantly (many minutes) slower than with Xcode 15. This happens for a new clone and any time an existing clone is reset using Product->Clean Build folder.

Configuration

Build times reported in this Issue were obtained with

LoopWorkspace dev, commit a32a19d (3.5.0)
Apple M1 MacBook Pro
Xcode 16.0
macOS 14.6

Previous Information

The initial discussion of this topic is on zulipchat:

https://loop.zulipchat.com/#narrow/stream/144182-development/topic/Xcode.2016.20Slow.20Builds

The gist is that when this parameter, ENABLE_MODULE_VERIFIER is set to YES in the project.pbxproj file, the initial build takes a long time with Xcode 16.

Additional Information

There are 19 submodules used by LoopWorkspace 3.4.1 and 3.5.0.

Of those, only 6 submodules have the ENABLE_MODULE_VERIFIER set in the Debug and Release sections and in all cases, it is set to YES. The number of entries in the project.pbxproj file per submodule is shown in the table below.

Repo	Instances
AmplitudeService	4
LibreTransmitter	4
LoopKit	7
MixpanelService	6
OmniBLE	2
OmniKit	6

Suggested Fix

There are 2 suggestions for fixing this problem.

Change the instances of that configuration from YES to a parameter that defaults to NO but could be modified to change the value without modifying the submodules again.
Remove the lines with that parameter in the project.pbxproj files completely

The rationale for Option 1 is that someone turned these on and there may be a reason why this was done.

The rationale for Option 2 is to be consistent with all the other submodules.

Both these options were tested and the improved timing is identical for either choice so long as the 12 instances of ENABLE_MODULE_VERIFIER = YES that matter are modified.

Timing Data

The timing for the build is taken from the Xcode tool.

All tests with Xcode 16.0
All initial builds preceded by Clean Build Folder, close workspace, open workspace
Use the menu sequence: Product, Perform Action, Build with Timing Summary
All times are reported in seconds
View the Build Timing Summary display

Report build time in seconds for first and subsequent builds in the table below. Multiple tests of a given configuration gave consistent results.

Config	First Build	Next Build
dev	490	20
modified	140	20

Timing Display for Initial Build: dev

The graphic below shows the timing display associated with the ENABLE_MODULE_VERIFIER = YES parameter for the initial build for Loop 3.4.1 or 3.5.0.

The items in the graphic above that begin with "Verify" are shown in the list below.

LoopKit
LoopKit-watchOS
LoopKitUI
AmplitudeService
AmplitudeServiceUIKit
MixpanelService
MixpanelServiceUI
OmniKit
OmniKitUI
OmniBLE
LibreTransmitter
LibreTransmitterUI

Timing Display for Initial Build: fix applied

The graphic below shows the timing display for the initial build when the submodules have the suggested fix applied.

@gestrich

Based on @gestrich comment in zulipchat, I looked at blame for these 6 modules.
Bill's comment:

I don't think it will make a difference if you will set them to NO vs removing the lines in terms of how it works (assuming Xcode is defaulting to this being off when the line was removed).

There is a slight chance an Xcode update or migration would lead to Xcode writing those lines back to the file automatically. Xcode sometime's does maintenance to the project file to fill in certain missing things. So personally I'd probably set to NO to be explicit but that's a very minor consideration without evidence that will happen for this setting.

Given the fact that I trust Bill over myself, I would have selected Option 1. And Deniz had a few comments sent via personal messages.

The blame results (these lines were added as part of commits for other changes), reinforced what Bill said.

I suggest that Option 1 - set the parameter explicitly instead of removing it - is the better fix for this issue.

Summary of Blame results

Look at blame: (save figures as blame-submodulename.png)

AmplitudeService: ps2; 2023-04-23; comment: Xcode project updates; LoopKit/AmplitudeService@99c2172

LibreTransmitter: ps2; 2023-06-23; comment: Updating to use DisplayGlucosePreference; LoopKit/LibreTransmitter@1ef522f

LoopKit: ps2; 2023-05-08; comment: Update project, and fix build warning; LoopKit/LoopKit@4f30d43

MixpanelService: Camji55; 2023-05-30; comment: Initial commit; LoopKit/MixpanelService@61b9c59

OmniBLE: ps2; 2023-05-06; comment: Cleanup unused files; LoopKit/OmniBLE@dbfa4b6

OmniKit: ps2; 2023-05-06; comment: Cleanup unused files; LoopKit/OmniKit@fa10903

Blame figures

AmplitudeService

LibreTransmitter

LoopKit

MixpanelService

OmniBLE

OmniKit

Final Test. Used the dnzxy:module-verify branch for the submodules in the 6 PR. (Option 1 fix).
Downloaded latest version for each at 2024-10-01 08:10 am PDT.

The Xcode 16.0 timing display for the initial build of LoopWorkspace dev with the 6 PR applied is shown below. The build time is down to ~140 sec, compared to ~490 sec before making this modification.

@ps2

Status: Some of the submodule PR were merged and this speeds up Xcode 16 builds somewhat.
@ps2 believes a fix will probably be pushed for Xcode later

he accepted for Loop 3.4.3 the submodules in which the PR were already merged, but doesn't plan to merge the others
these updated submodules are not (yet) updated to LoopWorkspace dev

Closing this PR for now.

Reopen this issue.

The slow build (30 seconds per verify module) has not been fixed with Xcode 16.1.
For example the tidepool-merge branch still has 7 submodules that take 30 sec each for an extra 3.5 minutes for the initial build for each phone.
A minor annoyance that really adds up when doing a lot of testing.

These first PR was modified to use "NO" instead of "$(CLANG_MODULES_ENABLE_VERIFIER_TOOL)".
The other 2 can also be modified if they will be accepted.

It would be nice if they could be included:

@ps2

The tidepool-merge branch submodules were updated to speed up Xcode builds. The build is now much faster. Thanks @ps2.

Navigation Menu

Repository navigation

Xcode 16 Builds very slowly #2235

Describe the bug

Configuration

Previous Information

Additional Information

Suggested Fix