Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager by email or DM. When contacting the review manager directly, please put "SE-0545" in the subject line.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at:
I'm already thinking of the possibility of incorporating such build performance info in CI.
Which makes me have to ask. What clocks do the measurements use? With a little bit of digging into Trace Event Format, I can see it already supports wallclock and threadtime at least, in the format itself, so I guess I'm just trying to ensure that these new SwiftPM build performance debugging tools do indeed expose times for both wallclock and some other clock that skips the suspension times.
Build traces use wall clock time because they operate at the granularity of individual build tasks and suspension is rarely interesting from a build performance perspective.
So the reason I asked about it is that GitHub Actions runners are already pretty noisy and a metric like cpu-user metigates observability of some of that noise.
Again I'm just thinking ahead and not sure how common it is to measure non-wallclock time in builds, but if the only option is wallclock then I might have to just skip the whole idea of benchmarking build perf in GHA runners.
The idea is that we should be able to try to optimize build times of a library and have benchmarks for it. Just like having tests or performance benchmarks.
One could use other metrics such as instructions count and it'd be ok but instruction count is only a coarse metric of keeping track of build performance when the goal is to decrease build times, so it'd be suboptimal.
A suspending clock suspends only when the machine/VM the build is running on sleeps/hibernates/etc, so it doesn't meaningfully eliminate noise caused by competition for resources. The goal of tracing at the build task level is primarily to:
Identify structural configuration issues that hurt parallelism
Identify which tasks in a build are most expensive relative to others
In the latter case, investigating the issue further often requires to switching to another tool like -ftime-trace, a CPU profiler, etc. The goal isn't to replace these tools, but to more quickly point users towards the area they should focus on.
Benchmark-style analysis is really a completely different use case from this type of investigatory debugging, and I think it requires a different set of tools that are outside the scope of this proposal.
In my experience with micro-benchmarks it does eliminate some noise even on dedicated-cpu-core machines (let alone shared-cpu-core machines of CI builders). It doesn't/shouldn't make things too much faster (if it does then there might either be an issue or you might want to use wallclock anyway to count that time as well).
Furthermore, I'm not too familiar with Swift's build system and you might be practically right, but a suspending clock can also skip times that you're waiting on IO or on a lock (or at least the part of the lock that's not just spinning).
About Swift's build system specifically, it's known to be RAM hungry. In server-side we used to (before LLMs steal our hobby) frequently have reports about OOM-kills in builder machines, such as Digital Ocean's builders, which only have/had 4GB of ram. And worse, sometimes even GHA builders which have 16GB of ram. Counting wallclock times in those situations would be suboptimal as the compiler is frequently fighting for resources, waiting on IO, or more frequently, on DRAM.
Considering my limited knowledge of build systems, I don't think I can have a definite opinion on what to do, so I'm just trying to mention these cases so maybe there is something that you think you should do. For example maybe I should just go for Clang's -ftime-trace instead.