Correct the maximal floating point width. Although technically, Android
could support FP128 on AArch64, Swift does not currently support FP128.
For now, ensure that we use FP64 on Android.
Outline the cold, non-contiguous UTF-8 path from String(decoding:as:),
saving ~40 bytes (33%) of code size (x86_64 and arm64) from every call
site where the contiguity check cannot be constant folded away.
Add concrete overloads for ~= for String/Substring
combinations. SR-12457 tracks making this generic after we understand
the expression type checker impact.
Round up our malloc requests and assert that breadcrumbs are aligned
and where we think they should be. This is necessary because ASAN
doesn't give us pointer-rounded sizes.
We have (and important!) assertion that our claimed allocation is
complete and the breadcrumbs are falling where we expect them
to. Something about ASAN changes the allocation behavior. Temporarily
disable this assertion until I can figure how to work with ASAN here.
* Don't allocate breadrumbs pointer if under threshold
* Increase breadrumbs threshold
* Linear 16-byte bucketing until 128 bytes, malloc_size after
* Allow cap less than _SmallString.capacity (bridging non-ASCII)
This change decreases the amount of heap usage for moderate-length
strings (< 64 UTF-8 code units in length) and increases the amount of
spare code unit capacity available (less growth needed).
Average improvements for moderate-length strings:
* 64-bit: on average, 8 bytes saved and 4 bytes of extra capacity
* 32-bit: on average, 4 bytes saved and 6 bytes of extra capacity
Additionally, on 32-bit, large-length strings also gain an average of
6 bytes of extra spare capacity.
Details:
On 64-bit, half of moderate-length allocations will save 16 bytes
while the other half get an extra 8 bytes of spare capacity.
On 32-bit, a quarter of moderate-length allocations will save 16
bytes, and the rest get an extra 4 bytes of spare
capacity. Additionally, 32-bit string's storage class now claims its
full allocation, which is its birthright. Prior to this change, we'd
have on average 1.5 bytes of spare capacity, and now we have 7.5 bytes
of spare capacity.
Breadcrumbs threshold is increased from the super-conservative 32 to
the pretty-conservative 64. Some speed improvements are incorporated
in this change, but more are in flight. Even without those eventual
improvements, this is a worthwhile change (ASCII is still fast-pathed
and irrelevant to breadcrumbing).
For a complex real-world workload, this amounts to around a 5%
improvement to transient heap usage due to all strings and a 4%
improvement to peak heap usage due to all strings. For moderate-length
strings specifically, this gives around 11% improvement to both.
Confirmed this change on using the swift-5.2-DEVELOPMENT-SNAPSHOT-2020-01-22-a
toolchain, Apple Swift version 5.2-dev (Swift d3f0448a4c).
Fixes rdar://problem/58717942
