[Docs] Update OptimizationTips for 'id-as-Any'

[karwa]

What's in this pull request?

Now that value types may also be bridged to Objective-C classes, using an Array of value types is no longer sufficient to eliminate internal bridging-related calls.

Resolved bug number: (SR-)

---

Before merging this pull request to apple/swift repository:

• Test pull request on Swift continuous integration.

Triggering Swift CI

The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:

Smoke Testing

Platform	Comment
All supported platforms	@swift-ci Please smoke test
All supported platforms	@swift-ci Please smoke test and merge
OS X platform	@swift-ci Please smoke test OS X platform
Linux platform	@swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

1. Builds the compiler incrementally.
2. Builds the standard library only for macOS. Simulator standard libraries and
   device standard libraries are not built.
3. lldb is not built.
4. The test and validation-test targets are run only for macOS. The optimized
   version of these tests are not run.

A smoke test on Linux does the following:

1. Builds the compiler incrementally.
2. Builds the standard library incrementally.
3. lldb is built incrementally.
4. The swift test and validation-test targets are run. The optimized version of these
   tests are not run.
5. lldb is tested.

Validation Testing

Platform	Comment
All supported platforms	@swift-ci Please test
All supported platforms	@swift-ci Please test and merge
OS X platform	@swift-ci Please test OS X platform
OS X platform	@swift-ci Please benchmark
Linux platform	@swift-ci Please test Linux platform

Lint Testing

Language	Comment
Python	@swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

Now that value types may also be bridged to Objective-C classes, using an Array of value types is no longer sufficient to eliminate internal bridging-related calls.

[gribozavr]

It is still true that Swift.Array<T> where T is not a class type only uses the Swift Array representation. Only when T is a class type (or an ObjC existential) the array can be in the NSArray representation.

[karwa]

@gribozavr yes, but you still get bridging-related calls. Here are two instruments traces, Array vs ContiguousArray with T as a plain-swift struct:

Array:

Weight  Self Weight     Symbol Name
10.59 s   96.7% 513.60 ms                  specialized specialized LineScanner.scanLines<A, B where ...> (from : A, carry : ScanRemainder<B>?, requiresByteSwap : Bool) -> ScanRemainder<B>?
7.61 s   69.4%  0 s                 specialized Array._copyToNewBuffer(oldCount : Int) -> ()
7.36 s   67.2%  100.00 µs                   specialized specialized _arrayOutOfPlaceUpdate<A, B where ...> (inout A, inout _ContiguousArrayBuffer<A.Element>, Int, Int, B) -> ()
247.40 ms    2.2%   0 s                  specialized specialized _ContiguousArrayBuffer.init(uninitializedCount : Int, minimumCapacity : Int) -> _ContiguousArrayBuffer<A>
100.00 µs    0.0%  0 s                  0x1167ad007
100.00 µs    0.0%  0 s                  <Unknown Address>
1.39 s   12.6%  100.00 µs                  free_large
584.20 ms    5.3%   109.30 ms                   specialized Array._appendElementAssumeUniqueAndCapacity(Int, newElement : A) -> ()
195.20 ms    1.7%   195.20 ms                   _swift_release_
80.40 ms    0.7%    18.10 ms                    specialized Array._getCount() -> Int
68.00 ms    0.6%    15.20 ms                    specialized _ArrayBuffer.capacity.getter
36.50 ms    0.3%    12.20 ms                    specialized Array._makeUniqueAndReserveCapacityIfNotUnique() -> ()
31.50 ms    0.2%    6.00 ms                 swift_bridgeObjectRetain
25.00 ms    0.2%    25.00 ms                    swift_bridgeObjectRelease
8.70 ms    0.0% 8.70 ms                 swift_objc_class_usesNativeSwiftReferenceCounting
8.00 ms    0.0% 8.00 ms                 object_getClass
7.90 ms    0.0% 7.90 ms                 swift_release
6.50 ms    0.0% 0 s                 <Unknown Address>
5.20 ms    0.0% 5.20 ms                 DYLD-STUB$$swift_bridgeObjectRelease
4.50 ms    0.0% 4.50 ms                 DYLD-STUB$$swift_getObjectType
4.50 ms    0.0% 4.50 ms                 DYLD-STUB$$swift_bridgeObjectRetain
3.90 ms    0.0% 3.90 ms                 DYLD-STUB$$object_getClass
3.70 ms    0.0% 3.70 ms                 DYLD-STUB$$swift_objc_class_usesNativeSwiftReferenceCounting
3.60 ms    0.0% 3.60 ms                 swift_isUniquelyReferenced_nonNull_native
3.30 ms    0.0% 3.30 ms                 DYLD-STUB$$swift_objc_class_unknownGetInstanceExtents
1.30 ms    0.0% 1.30 ms                 rt_swift_isUniquelyReferenced_nonNull_native
1.10 ms    0.0% 1.10 ms                 _swift_retain_
800.00 µs    0.0%  0 s                 _ContiguousArrayStorage.__deallocating_deinit
300.00 µs    0.0%  300.00 µs                  specialized _ArrayBuffer.isUniquelyReferenced() -> Bool
200.00 µs    0.0%  0 s                 swift_deallocClassInstance
200.00 µs    0.0%  0 s                 free
100.00 µs    0.0%  100.00 µs                  large_entry_for_pointer_no_lock

ContiguousArray:

Weight  Self Weight     Symbol Name
10.75 s   97.3% 576.70 ms                            specialized specialized LineScanner.scanLines<A, B where ...> (from : A, carry : ScanRemainder<B>?, requiresByteSwap : Bool) -> ScanRemainder<B>?
8.92 s   80.8%  0 s                           specialized ContiguousArray._copyToNewBuffer(oldCount : Int) -> ()
8.92 s   80.7%  100.00 µs                             specialized specialized _arrayOutOfPlaceUpdate<A, B where ...> (inout A, inout _ContiguousArrayBuffer<A.Element>, Int, Int, B) -> ()
8.92 s   80.7%  8.92 s                              _platform_memmove$VARIANT$Ivybridge
100.00 µs    0.0%  100.00 µs                              _platform_memmove$VARIANT$Nehalem
3.60 ms    0.0% 0 s                            specialized specialized _ContiguousArrayBuffer.init(uninitializedCount : Int, minimumCapacity : Int) -> _ContiguousArrayBuffer<A>
3.30 ms    0.0% 2.30 ms                             _swift_allocObject_
100.00 µs    0.0%  100.00 µs                              szone_size
100.00 µs    0.0%  100.00 µs                              swift_objc_class_unknownGetInstanceExtents
100.00 µs    0.0%  100.00 µs                              malloc_size
100.00 µs    0.0%  100.00 µs                             rt_swift_retain
1.23 s   11.1%  0 s                           free_large
14.90 ms    0.1%    14.90 ms                              swift_isUniquelyReferenced_nonNull_native
1.50 ms    0.0% 0 s                           _ContiguousArrayStorage.__deallocating_deinit
200.00 µs    0.0%  0 s                           free
200.00 µs    0.0%  0 s                           swift_deallocClassInstance

I'm not 100% sure what to make of it from an optimisation standpoint though - CA takes longer to copy, but A has all of those bridging calls. Maybe that's just noise and a quirk of my particular situation.

[gribozavr]

@karwa I don't see any bridging calls. swift_bridgeObjectRelease is just a reference-counting entry point which is almost as fast as Swift refcounting when we have Swift Array storage, but also has a fallback for Objective-C Array owners.

[karwa]

OK, yes, sure - you're right.

[jckarter]

@karwa Please file performance regressions you find as bugs. We're actively fixing a few things in this area, and it's premature to write up any advice based on the current state of things.

[karwa]

@jckarter After investigating some more (removing those big copies and bringing runtime down to 1.2s), it looks like there are still much bigger performance differences between Array and ContiguousArray than you would expect when T is a plain struct. Array is about twice as slow.

Filed https://bugs.swift.org/browse/SR-2196 with actual Instruments trace files

[jckarter]

@karwa Thanks!