A really simpleminded Collection view is faster by far than trying to cache all
that information.
I believe we could do even better by storing a simpler cache in the indices of
the view, but performance is already in decent shape, so we can put off
further optimization:
BASELINE
user 0m2.864s
user 0m2.775s
user 0m2.763s
SEQUENCE
user 0m2.632s
user 0m2.571s
user 0m2.553s
COLLECTION
user 0m3.553s
user 0m3.567s
user 0m3.475s
I had set up the driver to invoke a separate frontend invocation with
the "update code" mode. We sort of did this last release, except we
forked to the swift-update binary instead. This is causing problems with
testing in Xcode.
Instead, let's perform a single compile and add the remap file as an
additional output during normal compiles. The driver, seeing
-update-code, will add -emit-remap-file-path $PATH to the -c frontend
invocation.
rdar://problem/31857580
Implements Sequence and Collection views over arbitrary CodeUnits, demonstrating
that indexing is possible. However, collection-style decoding is approximately
3x slower than sequence-style, because Decoders have a fundamentally
Sequence-oriented interface. I think I know what needs to be done to get
parity.
Previously this would mean something like
class C {
private func f() {}
}
would end up with the symbol for f being completely public (external,
default visibility), even though it only needs to match the internal
class (external, hidden visibility).
I've opened https://bugs.swift.org/browse/SR-4714 to track fixing the
slowness here and/or moving the test into the validation suite.
We're currently not "too complex" here given the current metric, but we
are still extremely slow, adding several minutes to test runs.
This keeps us from showing Swift 3 names in Swift 4 code;
unfortunately, as the test case shows, we still have a few cases where
Swift /4/ names will leak into Swift /3/ code. I'm considering this an
acceptable state of events for now.
This means all cross-module references and all mangled names will
consistently use the Swift 4 name (the canonical type), no special
handling required.
The main thing we lose here is that the Swift 4 names of imported
types become usable in Swift 3 mode without any diagnostics, similar
to how most language features introduced in Swift 4 are available in
Swift 3 mode. It also implies that the Swift 4 name will show up in
demangled names.
rdar://problem/31616162
conversions and extend lifetimes over the call.
Apply this logic to string-to-pointer conversions as well as
array-to-pointer conversions.
Fix the AST verifier to not blow up on optional pointer conversions,
and make sure we SILGen them correctly. There's still an AST bug
here, but I'll fix that in a follow-up patch.
A variety of enhancements from SE-154 and SE-165:
- Custom Keys and Values collections for Dictionary
- Two sequence-based Dictionary initializers
- Merging methods for Dictionary
- Capacity checking and reserving for Dictionary and Set
- Type-specific filter(_:) methods for Dictionary and Set
- A mapValues(_:) method for Dictionary
- A grouping Dictionary initializer
This finally makes us measurably faster than the BASELINE, existing code in
master:
BASELINE
user 0m2.869s
user 0m2.890s
user 0m2.893s
FORWARD
user 0m2.727s
user 0m2.730s
user 0m2.737s
REVERSE
user 0m2.417s
user 0m2.418s
user 0m2.416s
