Hey Tim — running this against our iOS app at Reclip (audio-social, AVAudioEngine + Accelerate heavy, mid-migration to Swift 6 strict concurrency) and the day-over-day total is exactly what we needed for visibility.
One thing we're hitting: the migration has roughly doubled our clean build times (lots of new Sendable conformances + isolation annotations cascading through the audio graph), but incremental builds are barely impacted. The single aggregate number ends up averaging the two into a misleading middle value that doesn't reflect either developer experience accurately.
Did you ever consider splitting the output into clean vs incremental columns — i.e. tagging each measurement with the build type — or is there a reason that's harder than I'm assuming? Happy to throw a PR up if you'd be open to it; mostly want to make sure I'm not stepping on something you already tried.
— Dan
Hey Tim — running this against our iOS app at Reclip (audio-social, AVAudioEngine + Accelerate heavy, mid-migration to Swift 6 strict concurrency) and the day-over-day total is exactly what we needed for visibility.
One thing we're hitting: the migration has roughly doubled our clean build times (lots of new
Sendableconformances + isolation annotations cascading through the audio graph), but incremental builds are barely impacted. The single aggregate number ends up averaging the two into a misleading middle value that doesn't reflect either developer experience accurately.Did you ever consider splitting the output into clean vs incremental columns — i.e. tagging each measurement with the build type — or is there a reason that's harder than I'm assuming? Happy to throw a PR up if you'd be open to it; mostly want to make sure I'm not stepping on something you already tried.
— Dan