Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Performance improvements and availability updates for Collection.difference(from:using:) #25808
This PR dramatically improves the runtime performance of collection diffing. As near as I can tell the improvement is a constant factor in the neighbourhood of 50x.
It also adds benchmarks for both the Myers algorithm in addition to the collection diffing implementation itself, as the latter is expected to benefit from algorithmic improvements in the future.
Finally, it updates the availability macros now that
I'm also a perplexed by the availability markings and especially the
Isn't this SR-0240? There it said:
The language mode used at compile time is not related to the version of the stdlib that the code is actually running on. (For example, Swift 5 code can and will routinely run on 5.1 stdlib, and vice versa.) For production code, it is the runtime OS version that determines what features are actually available.
The situation is slightly different for us contributors, because we are building our own toolchains from GitHub, and features aren't necessarily tied to OS releases. However, it's a good enough approximation to suffice for now.
Having a separate version number for the stdlib isn't necessarily a bad idea, but I see it mostly as a convenience feature for stdlib contributors -- an extra indirection that would get rid of the need to list every OS on every single new API (not to mention 9999 placeholders). All app developers want to know is which OS version they need to target to start using specific stdlib features. E.g., to use
Some (member-level) improvements can be backward deployable, but any use of newly added types will need availability checks (or a minimum deployment target that matches the type's availability).
The standard library that shipped in macOS 10.14.4 does not include a
referenced this pull request
Jul 12, 2019
Linux and all other platforms exist in the fallback
We only have binary stability on Apple platforms in this release; on other platforms, Swift binaries need to be deployed with their own dedicated copy of the Swift runtime, like iOS/macOS apps did before this year.
Because Swift binaries on Linux can only ever run on the particular stdlib version they were compiled for, availability concerns don't apply there.