-
Notifications
You must be signed in to change notification settings - Fork 49
More benchmarker features #595
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
- Compare with NS regular expression - Save comparison results - Save and compare estimated compile times
A bad one because I have no idea how to use Swift Charts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
📊
BarMark( | ||
x: .value("Name", name), | ||
y: .value("Normalized runtime", new / old)) | ||
.foregroundStyle(LinearGradient( | ||
colors: [.accentColor, new - old <= 0 ? .green : .yellow], | ||
startPoint: .bottom, | ||
endPoint: .top)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could inline this into the ForEach { ... }
. I pulled this out to chartBody
because of "expression too complex". That doesn't happen with just one bar mark.
@swift-ci test |
Oh huh what version is the CI on?
|
I don't think the CI runs on macOS 13. Maybe |
return false | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This kind of approach looks ok to me. I wonder if we can generalize the interface a little bit to give us some future flexibility without needing to add more SPI over time. For example, we could return a (resilient) result type which we can add metrics to in the future (number of instructions, complexity or star-height, etc). We could also have a (resilient) compilation options parameter, such as the proposed force-recompilation behavior which we could extend with more options like control over optimizations or even targeted engine version (e.g. back deployment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may also want to output per-stage metrics, like time spent parsing vs generating bytecode, etc.
|
@swift-ci test |
@milseman Could you check that |
Sources/RegexBenchmark/Debug.swift
Outdated
@@ -6,7 +6,7 @@ extension Benchmark { | |||
case .whole: | |||
let result = target.wholeMatch(of: regex) | |||
if let match = result { | |||
if match.0.count > 100 { | |||
if match.0.count > 1000 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could / should we abstract this check out to a helper method somewhere?
static let disableOptimizations = CompileOptions(rawValue: 1) | ||
static let `default`: CompileOptions = [] | ||
@_spi(RegexBenchmark) | ||
public struct CompileOptions: OptionSet { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's underscore the name. Not a huge deal, but it makes it easier if we one day want API named CompileOptions
@@ -89,6 +89,8 @@ struct Processor { | |||
// MARK: Metrics, debugging, etc. | |||
var cycleCount = 0 | |||
var isTracingEnabled: Bool | |||
let shouldMeasureMetrics: Bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While well-predicted, do we see any impact from checking this bool inside the processor? Worst case we could make it conditionally compile and the benchmark can enable it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After looking around it doesn't seem like swiftPM supports the feature of "define this compilation variable only when being built as a dependency for target X". The only conditions it can enable/disable compilation variables on are platforms and debug/release. Trying to add multiple targets with flags enabled/disabled for _StringProcessing
ends up with "overlapping source code"
https://forums.swift.org/t/swiftpm-and-conditional-compilation/36874
https://forums.swift.org/t/compilation-conditions-and-swift-packages/34627/4
So for now in order to use metrics/tracing you just have to rebuild with the flag directly swift build -c release -Xswiftc -DPROCESSOR_MEASUREMENTS_ENABLED
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM after making sure to underscore the SPI
Ideally this would be done in Package.swift instead of having to add a flag to swift build but alas it appears that it is not possible - https://forums.swift.org/t/swiftpm-and-conditional-compilation/36874 - https://forums.swift.org/t/compilation-conditions-and-swift-packages/34627/4
@swift-ci test |
@swift-ci test |
@swift-ci test |
augh I forgot to switch it back to squash... oops |
Adds
Regex
)