* Add benchmarks that measure KeyPath read and write performance.
* Added setUpFunctions. Revised number of iterations per benchmark.
* Include n as a factor in the number of iterations.
* Increased number of iterations for KeyPathDirectAccess by a factor of 25.
* One last tweak to the number of iterations on testDirectAccess to get them above 20 us.
* Made revisions based on feedback. Added three new benchmarks.
* Added benchmarks to exhaustively benchmark all KeyPathComponent types. Removed benchmarks dealing with an inlining issue.
* Wrapped additional keypaths with identity() where needed. More cleanup and documentation.
* Moved KeyPaths for KeyPathRead and Write into FixedSizeArrayHolder. Renamed GetSet to Getset.
* Added inline(never) to both versions of getKeypathToElement().
* Moved identity() wraps so that they're called once per variable per benchmark.
* Moving destinationKeyPaths into FixedSizeArrayHolder to try to reduce long setup overhead errors.
* Additional moving of the identity() wrapping into the singleton's init() to try to reduce setup time errors.
The script defaulted to a mode that no one uses without checking
whether the input was compatible with that mode.
This is the script used for run-to-run comparison of benchmark
results. The in-tree benchmarks happened to work with the script only
because of a fragile string comparison burried deep within the
script. Other out-of-tree benchmark scripts that generate results were
silently broken when using this script for comparison.
Function bodies of `blackHole`, `identity`, etc. must not be visible in the benchmark modules.
Enabling CMO by default broke this. Since then we need to explicitly exclude those functions from cross-module-optimization.
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
Add a new benchmark module StringSplitting for split-like benchmarking.
Add lineSink benchmarks, which separates Unicode content by lines and feeds
Strings into a sink.
* Add differentiation benchmarks.
* Make install name of _Differentiation be @rpath/libswift_Differentiation.dylib.
Co-authored-by: Marc Rasi <marcrasi@google.com>
Clean up a few general patterns that are now obviated by canImport
This aligns more generally with the cleanup that the Swift Package
Manager has already done in their automated XCTest-plumbing tool in
apple/swift-package-manager#1826.
This patch adds a benchmark to the Swift benchmark suite based on the
ChaCha20 encryption algorithm.
As Swift evolves it is important that it tackles more and more features
and possible use cases. One of these great use-cases is low-level CPU
intensive code, and cryptographic algorithms are a really important
test-bed.
This benchmark therefore provides a real-world test case for Swift's
optimiser. My ideal outcome here is that Swift should be able to perform
as well at this benchmark as a naive equivalent C implementation.
Specifically, I add some benchmarks for weak, unowned, unsafe (unowned), and
unmanaged. The reason for the split in between unsafe (unowned) and unmanaged is
that one is testing the raw compiler features and the other is validating stdlib
performance.
FindStringNaive is a simple benchmark which implements a naive String
finding algorithm that currently shows a lot of ARC traffic, hopefully
to be reduced in the future.
This currently copies the array each time it swaps elements. This
makes it 1500x slower than it should be to sort the array. The
benchmark now runs in 15ms but should be around 10us when fully
optimized.
This algorithm is an interesting optimization problem involving array
optimization, uniqueness, bounds checks, and exclusivity. But the
general first order problem is how to modify a CoW data structure
that's stored in a class property. As it stands, the property getter
retains the class property around the modify accesses that checks
uniqueness.
