Adds KeyPath test to benchmark suite

[taylorGeisler]

This pull request adds a test of KeyPaths performance to the benchmark suite. It creates a fixed size array struct and KeyPaths to its properties. It does work inside of a loop by accessing the properties with KeyPaths.

[CodaFi]

@swift-ci smoke test

[CodaFi]

@swift-ci benchmark

[swift-ci]

Performance: -O

Regression	OLD	NEW	DELTA	RATIO
ObjectiveCBridgeStubToNSStringRef	110	127	+15.5%	0.87x (?)
Improvement	OLD	NEW	DELTA	RATIO
FlattenListFlatMap	6618	3925	-40.7%	1.69x (?)
NSError	269	162	-39.8%	1.66x (?)
NSStringConversion.UTF8	1056	980	-7.2%	1.08x (?)
Added	MIN	MAX	MEAN	MAX_RSS
KeyPath	1359	1421	1380	—

Code size: -O

Performance: -Osize

Improvement	OLD	NEW	DELTA	RATIO
StringFromLongWholeSubstring	5	4	-20.0%	1.25x
CharacterLiteralsLarge	111	100	-9.9%	1.11x (?)
UTF8Decode_InitFromData_ascii_as_ascii	697	629	-9.8%	1.11x (?)
CharacterLiteralsSmall	345	322	-6.7%	1.07x (?)
Added	MIN	MAX	MEAN	MAX_RSS
KeyPath	1354	1410	1373	—

Code size: -Osize

Performance: -Onone

Improvement	OLD	NEW	DELTA	RATIO
DataToStringLargeUnicode	9450	8600	-9.0%	1.10x (?)
Added	MIN	MAX	MEAN	MAX_RSS
KeyPath	1191092	1201186	1194621	—

Code size: -swiftlibs

✅	Benchmark Check Report
⛔️⏱	KeyPath has setup overhead of 1368 μs (100.1%). Move initialization of benchmark data to the setUpFunction registered in BenchmarkInfo.
⚠️⏱	KeyPath execution took -1 μs. Increase the workload of KeyPath to be more than 20 μs.

How to read the data

The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview

  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

[eeckstein]

The key path accesses are all optimized away. You can use identity to prevent that, e.g.

    let kp0 = identity(FixedSizeArray10<Double>.getKeypathToElement(index: 0))

Also, it would be nice to benchmark other key path operations, like: subscripts, getters, setters.

[taylorGeisler]

@swift-ci benchmark

[eeckstein]

@swift-ci benchmark

[swift-ci]

Build failed before running benchmark.

[taylorGeisler]

@eeckstein Overall I'd like this benchmark to highlight the performance difference between the KeyPath and Direct Access implementations in working with struct properties. Any further suggestions?

[eeckstein]

Overall I'd like this benchmark to highlight the performance difference between the KeyPath and Direct Access implementations

The difference between both benchmarks is not reported in a benchmark run, e.g. on CI. So the only way to see the difference is to compile the benchmarks locally and manually compare both results.
And runStructDirectAccessComputation as a stand-alone benchmark is not very useful, IMO.

You can keep runStructDirectAccessComputation if you think you'd like to do this manual comparison by your own, but then please add the skip tag, so that it does not run by default.
Or you just delete the benchmark.

[eeckstein]

lgtm, thanks!

[eeckstein]

@swift-ci benchmark

[eeckstein]

@swift-ci smoke test

[eeckstein]

@swift-ci benchmark

[swift-ci]

Performance: -O

Regression	OLD	NEW	DELTA	RATIO
FlattenListLoop	1631	2510	+53.9%	0.65x (?)
FlattenListFlatMap	4432	6712	+51.4%	0.66x (?)
Improvement	OLD	NEW	DELTA	RATIO
DictionaryKeysContainsNative	30	26	-13.3%	1.15x (?)
ObjectiveCBridgeStubToNSStringRef	119	110	-7.6%	1.08x (?)
Added	MIN	MAX	MEAN	MAX_RSS
StructKeyPathComputation	1216726	1219019	1217986	—

Code size: -O

Performance: -Osize

Improvement	OLD	NEW	DELTA	RATIO
ObjectiveCBridgeStubToNSStringRef	133	121	-9.0%	1.10x (?)
ObjectiveCBridgeFromNSArrayAnyObjectForced	5200	4760	-8.5%	1.09x (?)
Added	MIN	MAX	MEAN	MAX_RSS
StructKeyPathComputation	1287360	1297421	1293962	—

Code size: -Osize

Performance: -Onone

Regression	OLD	NEW	DELTA	RATIO
NSError	728	791	+8.7%	0.92x (?)
Added	MIN	MAX	MEAN	MAX_RSS
StructKeyPathComputation	1436021	1460507	1451122	—

Code size: -swiftlibs

✅	Benchmark Check Report
⛔️⏱	StructKeyPathComputation has setup overhead of 1315368 μs (104.6%). Move initialization of benchmark data to the setUpFunction registered in BenchmarkInfo.
⚠️⏱	StructKeyPathComputation execution took -58365 μs. Increase the workload of StructKeyPathComputation to be more than 20 μs.

How to read the data

The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview

  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

[eeckstein]

@taylorGeisler I just saw that you moved the keypath variables out of the function and made them global. That is not good, because accesses to (non-trivial) globals is slow.
Please move those variables back into the function.

[BradLarson]

My coworker (from the same company that originated this PR) has been working on a more extensive set of keypath benchmarks in #60383, so I believe it is safe to close out this PR in favor of that newer one.