The `legacyFactor` is 11 instead of 10, because of the wierd way the `repeatCount` translates to the workload size based on the number of lines in the `workloadBase`… it’s just so.
Lowered the workload of string appending bechmarks a bit further, to get them under 1ms in `O` and 10ms in `Onone` builds.
Fine tuned the legacy factor to match original `O` runtimes — the changes are non-linear because of complications from double loop and amortized array growth costs.
These string appending benchmarks along with
* ArrayPlusEqualFiveElementCollection and
* ArrayPlusEqualSingleElementCollection
are likely to show different performance in `Osize` and `Onone` builds because of the non-linearity of their original implementation.
Cleaned up doubled inner loops and applied legacyFactor to the resulting, more rational, workload sizes.
Factors for string appending benchmarks are not 10, but 11 to compensate for smaller amortized Array resizes. Similarily ArrayPlusEqualFiveElementCollection’s factor is 49.
Reintroduce Ackermann benchmark with reasonably sized workload. Since this one was tagged `.unstable`, there’s no need to go through `legacyFactor`.
Adjusted `lit` test for Benchmark_O now that Ackermann isn’t marked `.unstable` anymore.
Removed incorrect `asserts` requirement from the benchmark lit tests.
Lowered the default sample cap from 2k to 200. (This doesn’t effect manually specified `--num-samples` argument in the driver.)
Swift benchmarks have pretty constant performance profile over time. It’s more beneficial to get multiple independent measurements faster, than more samples from the same run.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
The use of `--verbose` parameter was affecting the reported memory usage (`--memory`), because it front-loads initialization of string interpolation and printing.
By always computing the configuration string and always calling print, the baseline memory measurement no longer includes this constant overhead.
These should be audited since some might not actually need to be
@inlinable, but for now:
- Anything public and @inline(__always) is now also @inlinable
- Anything @usableFromInline and @inline(__always) is now @inlinable
After rebasing on master and incorporating more 32-bit support,
perform a bunch of cleanup, documentation updates, comments, move code
back to String declaration, etc.