(Old title: Overloaded Method Resolutions.)
I'm not 100% sure if this is a bug or a misunderstanding on my part of how overloaded methods work.
In order to conform to
Zip2Collection (part of a proposal I'm working on) needs to (1) provide an
Index that conforms to
Strideable or (2) provide O(1) implementations of
index(_:offsetBy:) (on top of the requirements set by
BidirectionalCollection). All other implementations, like
index(_:offsetBy:limitedBy:), etc., are built on top of these. I've opted for the second strategy.
During benchmarking I discovered that the default implementation of
count defined in
Collection doesn't make use of our overloaded O(1) implementation of
distance(from:to:) when using two
RandomAccessCollections. It makes use of the default O(n) implementation from
Steps to Reproduce
- Create a local copy of the code:
cd ~/Desktop && \ git clone https://github.com/dennisvennink/Zip.git && \ cd Zip && \ git checkout 8031b4a00cc1394613a2cd226e19e73f247857ed && \ swift package generate-xcodeproj && \ open Zip.xcodeproj
- Comment out
- Run the
- Run the benchmark again.
I see a huge difference in time performance (2000000% worse) on my machine (2,4 GHz Intel Core i7 MacBook Pro (17-inch, Late 2011) running macOS High Sierra 10.13.5 (17F77), Xcode 10.0 beta 6 (10L232m) and Swift 4.2 (swiftlang-1000.0.36 clang-1000.0.4)).
count(and all other methods). ¯\_(ツ)_/¯
It might be that I'm overlooking something, hence not directly filing a JIRA.
Any thoughts are welcome.