[Pitch] Elide `some` in Swift 6

[gwendal.roue (Gwendal Roué)]

@johnno1962

There were exceptions notably the problem where a function is intended to provide a conformance to a system protocol eg Decodable, Encodable etc (3 cases) and it seems you can't use some types for constructor arguments in the toolchain. Was there a reason for that?

I'm not sure I see what you are referring to. "Constructor arguments in the toolchain" ?

[johnno1962 (John Holdsworth)]

I'm seeing a new error from time to time:

/Users/johnholdsworth/Developer/GRDB.swift/GRDB/Core/FetchRequest.swift:227:28: error: 'some' types are only permitted in properties, subscripts, and functions
    public init(_ request: some FetchRequest<RowDecoder>) {
                           ^

But I'm seeing that also for some functions so it could just be a regression somewhere.

/Users/johnholdsworth/Developer/GRDB.swift/GRDB/QueryInterface/SQLInterpolation+QueryInterface.swift:9:56: error: 'some' types are only permitted in properties, subscripts, and functions
    public mutating func appendInterpolation(_ table: (some TableRecord).Type) {

Building off main always a bit of a mixed bag and your project has some very interesting edge cases. Are you in the source compatibility suite?

[gwendal.roue (Gwendal Roué)]

All the quoted snippets compile today (Swift 5.7).

@johnno1962

Are you in the source compatibility suite?

Add GRDB+Swift 5.7

[Ray_Fix]

Strong +1 from me, FWIW. I think that it makes the language easier to teach and learn. You only introduce any when you need its dynamic nature (and the indirection cost associated with it). APIs are more approachable, because they have less syntax noise. The sooner we tear off the bandaid, the better.

[Tino]

@Ray_Fix

You only introduce any when you need its dynamic nature (and the indirection cost associated with it).

Imo it is a misconception that those indirection costs are important, and I oppose the notion that some is somehow better than any. In the majority of cases, the cost advantage does not matter at all, so this is pushing towards premature optimization.
Although premature optimization is not always evil, any saves its users from trouble down the road, as many things simply work. Not sure if it still applies, but take Closures cannot use the `some` keyword? as an example.

I don't think a new default would make anything simpler to understand either, but this standpoint has been explained already.

[Karl]

Those costs are important; it is not a misconception. However, what is more important is to use the right tool for the right job - each can offer performance and expressivity benefits depending on the circumstance.

For example, an any Collection<Int> could be backed by an Array, Range<Int>, or RangeSet<Int>, depending on the data it happens to contain as discovered at runtime. It is difficult to express that kind of dynamism using generics. However, generics allow for greater compile-time optimisation, and the guarantee of having a single underlying type means that it is easier to reason about that type's associated types.

That said, the kind of dynamism which existentials excel at is actually rather rare in real applications. Generics are the more useful mechanism for type abstraction.

[jeremyabannister (Jeremy Bannister)]

@Karl

It is difficult to express that kind of dynamism using generics.

@Karl

having a single underlying type means that it is easier to reason about that type's associated types.

It it feasible to make these statements more concrete, i.e., by providing contrasting code examples where the relative difficulty/ease is clear to see?

[Karl]

Sure. But I've collapsed it so as not to distract from the topic at hand.

Dynamism

// We have a type Foo, containing some integers.
// We want to optimise the storage of those integers so contiguous regions
// are represented using Range<Int>.
//
struct Foo {
  var data: ???

  init(rawData: [Int]) {
    let rawData = ...
    if let range = makeRangeIfPossible(rawData) {
      self.data = range
    } else {
      self.data = rawData
    }
  }
}

This kind of pattern requires data to be an existential, because we want Foo to remain a single type while also containing data stored using one of multiple representations.

An alternative might be to make Foo generic (e.g. Foo<Storage>, with data being of type Storage), but that becomes extremely awkward, because code outside of Foo won't know whether a certain data set should result in a Foo<Array<Int>> or Foo<Range<Int>>.

In a broader sense, existentials allow type abstraction to be used internally by Foo as an implementation detail, without affecting Foo's external interface.

Associated Types

struct Bar<Container> where Container: MutableCollection {
  var container: Container

  mutating func someMutation() { ... }

  mutating func doSomethingElse() {

    let i: Container.Index = container.startIndex

    someMutation()

    // Because 'Container' is generic, we know that 'someMutation()'
    // could not have changed the type of 'container'.
    // In other words, 'i', and 'container.endIndex' still definitely 
    // refer to the same type.
    while i < container.endIndex {
      ...
    }
  }
}

If container were an existential, it is possible that someMutation() would change its underlying type, meaning that i and container.endIndex after the call refer to different types. Generics pin the type so it cannot change, while still keeping it abstract.

[Zollerboy1 (Josef Zoller)]

@Karl

// We have a type Foo, containing some integers.
// We want to optimise the storage of those integers so contiguous regions
// are represented using Range<Int>.
//
struct Foo {
  var data: ???

  init(rawData: [Int]) {
    let rawData = ...
    if let range = makeRangeIfPossible(rawData) {
      self.data = range
    } else {
      self.data = rawData
    }
  }
}

This kind of pattern requires data to be an existential, because we want Foo to remain a single type while also containing data stored using one of multiple representations.

I don't think that this kind of pattern requires an existential at all. IMHO, most of the times someone reaches for an existential for something like that, it would be much better written like this:

struct Foo {
    private enum Storage {
        case range(Range<Int>)
        case array([Int])

        init(rawData: [Int]) {
            if let range = makeRangeIfPossible(rawData) {
                self = .range(range)
            } else {
                self = .array(rawData)
            }
        }
    }

    private var data: Storage

    init(rawData: [Int]) {
        self.data = .init(rawData: rawData)
    }
}

[Karl]

@Zollerboy1

I don't think that this kind of pattern requires an existential at all. IMHO, most of the times someone reaches for an existential for something like that, it would be much better written like this:

We're getting away from the topic, but briefly: I disagree that an enum is necessarily "better". In this context, the only meaningful commonality between Array and Range is that they are both collections.

If you put these types in an enum, you will have to forward the conformances manually. I would argue that is not just a matter of the language being unhelpful and making us write tedious boilerplate, and actually makes complete sense: in general, different cases are semantically meaningful; it would be wrong to say that every enum with 2 collection payloads should conform to collection.

So this is something of an exceptional case, where there is no semantic meaning to the 2 cases, and the only thing that is meaningful is that there is a collection underneath - in other words, I think any Collection is the best expression of intent, and that these sorts of enums are basically hand-rolled existentials.

To emphasise that point, when we use one of the language's existentials, we do get automatic conformance forwarding, unboxing, and other nice features, automatically as part of the language, because we are precisely expressing that the collection conformance is all we care about.

Now, it may be that constraining the list of underlying types can lead to more efficient existential layout and dispatching, but I would also argue that is something that should be addressed by optimisation attributes (similar to @inlinable or @frozen). In other words, I think that if it is beneficial to manually write out an existential using an enum, we should consider that a defect and address it.

[CharlesS (Charles Srstka)]

While that's true, enums have significantly better performance characteristics than existentials, which can make the boilerplate worth it a lot of the time, especially if this is in a library that might get used by a wide variety of clients.

[taylorswift]

@CharlesS

While that's true, enums have significantly better performance characteristics than existentials, which can make the boilerplate worth it a lot of the time, especially if this is in a library that might get used by a wide variety of clients.

there's an exception to this: if you have an existential that's constrained to AnyObject, those have better performance than an enum of classes, since you are already paying for indirection.

i wouldn't want to use existentials to wrap any trivial value types or mid-size and above struct types though. the boilerplate needed to reinvent protocol dispatch is exhausting and i often feel like i have no choice but to endlessly switch over enums of struct types.

[johnno1962 (John Holdsworth)]

I've been benchmarking the performance of existentials using this script. The TL;DR is, existentials are less fast (sometimes dramatically so when the compiler starts cheating!) but they are fast enough to not be something you need to give too much attention to.

% swift -O ~/overhead.swift
class underlier  <- calls/sec for argument type ->
let storage  existential     generic         opaque
existential  178,456,720.78  488,280,374.15  485,837,035.14
opaque       226,465,126.95  5,324,748,000.  5,342,041,648.
concrete     228,034,958.47  5,816,939,185.  5,806,872,490.

class underlier  <- calls/sec for argument type ->
var storage  existential     generic         opaque
existential  186,295,937.67  489,117,401.82  489,548,420.22
opaque       226,280,029.56  5,807,274,489.  5,813,714,048.
concrete     223,463,810.97  5,574,196,292.  5,549,122,180.

class underlier  <- calls/sec for inout argument type ->
var storage  existential     generic         opaque
existential  486,928,417.19  487,519,861.44  486,003,105.37
opaque                       5,605,110,249.  5,653,081,744.
concrete                     5,687,963,113.  5,814,116,994.

struct underlier <- calls/sec for inout argument type ->
var storage  existential     generic         opaque
existential  285,566,717.61  5,513,017,875.  5,367,678,525.
opaque                       54,050,309,278  58,784,919,411
concrete                     59,158,025,387  59,535,897,799

This is from an M1 mini. I'd be interested to see the numbers from someone who has an M2.
Numbers for an iPhone SE with some weird differences:

class underlier  <- calls/sec for argument type ->
let storage  existential     generic         opaque
existential  391,604,912.91  442,537,495.31  443,047,021.48
opaque       4,330,945,325.  4,359,077,114.  4,334,749,896.
concrete     4,531,198,617.  4,524,843,842.  4,533,157,524.

class underlier  <- calls/sec for argument type ->
var storage  existential     generic         opaque
existential  138,385,455.07  139,014,276.6   138,946,810.48
opaque       4,591,465,790.  4,595,490,303.  4,595,490,303.
concrete     4,599,774,085.  4,574,439,960.  4,627,431,597.

class underlier  <- calls/sec for inout argument type ->
var storage  existential     generic         opaque
existential  442,595,867.71  439,599,211.83  439,541,627.15
opaque                       4,597,757,193.  4,606,341,222.
concrete                     4,602,045,205.  4,602,045,205.

struct underlier <- calls/sec for inout argument type ->
var storage  existential     generic         opaque
existential  227,863,378.80  239,268,441.55  239,228,182.84
opaque                       53,193,455,928  53,193,455,928
concrete                     53,193,455,928  52,363,345,817

Numbers from inside Xcode as opposed to using the script show these differences.

3rd EDIT
It's even weirder than that. Inside Xcode, if you insert the test code into a macOS app you get the script's performance pattern! How could performance be platform specific? Running it inside the iOS simulator gives the second pattern.

4th EDIT
It turns out, most of the differences between compiling for iPhone and running the script I posted on the command line disappear if you compile for "Whole Module Optimisation".

[hassila (Joakim Hassila)]

You may get slightly strange results getting tricked by the optimiser as your results look a bit wild, I was curious and just quickly refactored your test slightly here and used a blackHole: external-reproducers/benchmarks/elide-some at main · ordo-one/external-reproducers · GitHub
(reservations for any translation errors)

If you want to give it a spin:

git clone git@github.com:ordo-one/external-reproducers
cd external-reproducers/benchmarks/elide-some/
swift package benchmark --metric wallClock --grouping metric

Use --filter regex as in the other examples below if you want to run a certain subset for more easy comparison etc, see examples below.

Output for me (M1 Max):

Summary

Time (wall clock)
╒═════════════════════════════════════════════════════════╤═════════╤═════════╤═════════╤═════════╤═════════╤═════════╤═════════╤═════════╕
│ Test                                                    │      p0 │     p25 │     p50 │     p75 │     p90 │     p99 │    p100 │ Samples │
╞═════════════════════════════════════════════════════════╪═════════╪═════════╪═════════╪═════════╪═════════╪═════════╪═════════╪═════════╡
│ ElideSome:letAnyStorageWithConcrete (μs)                │    9601 │    9633 │    9666 │    9748 │    9814 │   10010 │   10067 │     310 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:letAnyStorageWithExistential (μs)             │    8978 │    9011 │    9035 │    9084 │    9142 │    9306 │    9486 │     332 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:letAnyStorageWithGeneric (μs)                 │    9912 │    9936 │    9953 │   10002 │   10067 │   10297 │   10469 │     301 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:letConcreteStorageWithConcrete (μs)           │    7434 │    7454 │    7479 │    7540 │    7589 │    7725 │    7782 │     400 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:letConcreteStorageWithExistential (μs)        │   10534 │   10559 │   10584 │   10633 │   10764 │   11059 │   11231 │     283 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:letConcreteStorageWithGeneric (μs)            │    7434 │    7446 │    7467 │    7516 │    7581 │    7774 │    8609 │     401 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:letSomeStorageWithConcrete (μs)               │    7434 │    7499 │    7548 │    7602 │    7675 │    7835 │    7925 │     397 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:letSomeStorageWithExistential (μs)            │   10543 │   10657 │   10723 │   10797 │   10911 │   11116 │   11223 │     280 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:letSomeStorageWithGeneric (μs)                │    7434 │    7487 │    7540 │    7593 │    7667 │    7876 │    7905 │     398 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varAnyStorageWithConcrete (μs)                │   13942 │   13983 │   14024 │   14098 │   14229 │   14475 │   14532 │     214 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varAnyStorageWithExistential (μs)             │   13942 │   13975 │   14000 │   14073 │   14229 │   14458 │   14893 │     214 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varAnyStorageWithGeneric (μs)                 │   14254 │   14286 │   14303 │   14368 │   14540 │   14802 │   15114 │     209 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varAnyStorageWithInoutConcrete (μs)           │   10223 │   10313 │   10362 │   10412 │   10477 │   10682 │   10797 │     290 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varAnyStorageWithInoutExistential (μs)        │    9601 │    9633 │    9658 │    9699 │    9789 │   10002 │   10059 │     310 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varAnyStorageWithInoutGeneric (μs)            │   10534 │   10575 │   10641 │   10698 │   10764 │   10993 │   11083 │     282 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varAnyStructStorageWithInoutConcrete (μs)     │    4333 │    4345 │    4358 │    4386 │    4448 │    4599 │    5509 │     685 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varAnyStructStorageWithInoutExistential (μs)  │    3717 │    3731 │    3749 │    3790 │    3833 │    3923 │    3966 │     797 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varAnyStructStorageWithInoutGeneric (μs)      │    4644 │    4669 │    4702 │    4751 │    4816 │    4939 │    5119 │     636 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varConcreteStorageWithConcrete (μs)           │   10534 │   10575 │   10616 │   10674 │   10715 │   10928 │   11223 │     283 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varConcreteStorageWithExistential (μs)        │   10534 │   10559 │   10584 │   10641 │   10706 │   10977 │   11034 │     283 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varConcreteStorageWithGeneric (μs)            │   10534 │   10567 │   10592 │   10657 │   10731 │   10928 │   10977 │     283 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varConcreteStorageWithInoutConcrete (μs)      │    8052 │    8077 │    8110 │    8163 │    8200 │    8396 │    8503 │     369 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varConcreteStorageWithInoutGeneric (μs)       │    8052 │    8122 │    8155 │    8183 │    8257 │    8421 │    8454 │     368 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varConcreteStructStorageWithInoutConcrete (μ… │     309 │     310 │     310 │     314 │     323 │     347 │     540 │    9539 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varConcreteStructStorageWithInoutGeneric (μs) │     309 │     310 │     310 │     312 │     322 │     351 │     402 │    9551 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varSomeStorageWithConcrete (μs)               │   10534 │   10551 │   10575 │   10641 │   10731 │   11001 │   11034 │     283 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varSomeStorageWithExistential (μs)            │   10534 │   10567 │   10600 │   10674 │   10780 │   10911 │   10993 │     283 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varSomeStorageWithGeneric (μs)                │   10534 │   10551 │   10575 │   10616 │   10706 │   10919 │   11157 │     283 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varSomeStorageWithInoutConcrete (μs)          │    8052 │    8110 │    8175 │    8232 │    8318 │    8421 │    8437 │     367 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varSomeStorageWithInoutGeneric (μs)           │    8052 │    8110 │    8159 │    8208 │    8265 │    8413 │    8544 │     368 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varSomeStructStorageWithInoutConcrete (μs)    │     309 │     310 │     310 │     314 │     323 │     348 │     429 │    9535 │
├─────────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varSomeStructStorageWithInoutGeneric (μs)     │     309 │     310 │     310 │     312 │     318 │     334 │     415 │    9596 │
╘═════════════════════════════════════════════════════════╧═════════╧═════════╧═════════╧═════════╧═════════╧═════════╧═════════╧═════════╛

In general I disagree with the fast enough sentiment, for example the letSomeStorage case has significant differences:

Summary

swift package benchmark --metric wallClock --grouping metric --filter "letSomeStorage.*"
...
Time (wall clock)
╒═════════════════════════════════════════════╤═════════╤═════════╤═════════╤═════════╤═════════╤═════════╤═════════╤═════════╕
│ Test                                        │      p0 │     p25 │     p50 │     p75 │     p90 │     p99 │    p100 │ Samples │
╞═════════════════════════════════════════════╪═════════╪═════════╪═════════╪═════════╪═════════╪═════════╪═════════╪═════════╡
│ ElideSome:letSomeStorageWithConcrete (μs)   │    7434 │    7454 │    7471 │    7495 │    7553 │    7905 │    8355 │     401 │
├─────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:letSomeStorageWithExistential (μ… │   10534 │   10567 │   10584 │   10625 │   10739 │   11157 │   11395 │     283 │
├─────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:letSomeStorageWithGeneric (μs)    │    7434 │    7458 │    7475 │    7507 │    7684 │    7995 │    9355 │     399 │
╘═════════════════════════════════════════════╧═════════╧═════════╧═════════╧═════════╧═════════╧═════════╧═════════╧═════════╛

Also in terms of ARC traffic:

Summary

swift package benchmark --metric retainCount --grouping metric --filter "letSomeStorage.*"

Retains
╒═════════════════════════════════════════════╤═════════╤═════════╤═════════╤═════════╤═════════╤═════════╤═════════╤═════════╕
│ Test                                        │      p0 │     p25 │     p50 │     p75 │     p90 │     p99 │    p100 │ Samples │
╞═════════════════════════════════════════════╪═════════╪═════════╪═════════╪═════════╪═════════╪═════════╪═════════╪═════════╡
│ ElideSome:letSomeStorageWithConcrete        │       1 │       1 │       1 │       1 │       1 │       1 │       1 │     398 │
├─────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:letSomeStorageWithExistential (K) │     999 │    1000 │    1000 │    1000 │    1000 │    1000 │    1000 │      90 │
├─────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:letSomeStorageWithGeneric         │       1 │       1 │       1 │       1 │       1 │       1 │       1 │     399 │
╘═════════════════════════════════════════════╧═════════╧═════════╧═════════╧═════════╧═════════╧═════════╧═════════╧═════════╛

That being said, there are some quite surprising results too (which might be worth digging into), e.g.:

Summary

swift package benchmark --metric wallClock --grouping metric --filter "varAnyStruct.*"

Time (wall clock)
╒═══════════════════════════════════════════════════════╤═════════╤═════════╤═════════╤═════════╤═════════╤═════════╤═════════╤═════════╕
│ Test                                                  │      p0 │     p25 │     p50 │     p75 │     p90 │     p99 │    p100 │ Samples │
╞═══════════════════════════════════════════════════════╪═════════╪═════════╪═════════╪═════════╪═════════╪═════════╪═════════╪═════════╡
│ ElideSome:varAnyStructStorageWithInoutConcrete (μs)   │    4333 │    4354 │    4370 │    4399 │    4472 │    4775 │    4976 │     683 │
├───────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varAnyStructStorageWithInoutExistential (μ… │    3717 │    3731 │    3756 │    3803 │    3846 │    4126 │    4268 │     794 │
├───────────────────────────────────────────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ ElideSome:varAnyStructStorageWithInoutGeneric (μs)    │    4644 │    4669 │    4689 │    4739 │    4784 │    4988 │    5296 │     637 │
╘═══════════════════════════════════════════════════════╧═════════╧═════════╧═════════╧═════════╧═════════╧═════════╧═════════╧═════════╛

[johnno1962 (John Holdsworth)]

I can't deny the results I processed are pretty wild and surprising in many ways; Optimisers move in mysterious ways for sure. If I understand "using a blackhole" turns off the optimiser and inlining. Surely it's what the optimiser does that counts though for a Release build? Looking at the assembly in some cases it is replacing the ten dispatches to the incrementing method with a single instruction adding 10 to the count in the underling type. I'm assuming this is what happens when you get 5 billion increments a second. I have no idea what it is doing for the 50 billion-odd increments per second recorded for structs.

Taking a step back to the fast enough debate, the worst case seems to hover around 150 million dispatches a second though it could be less in certain cases I've not been able to contrive. I can't imagine a program that would need to do that and if it did move the inner loop inside the function call.

[FranzBusch]

These tests are only showing the overhead of the existential call but the larger impact most of the times is that the optimizer cannot look through the existential and therefor cannot specialize code.

This is really noticeable when there are more generics „hidden“ behind the existential. @hassila tests are exercising this already more but it gets worse the more generic code the optimizer can’t specialize

[ksluder (Kyle Sluder)]

@FranzBusch

This is really noticeable when there are more generics „hidden“ behind the existential. @Joakim_Hassila1 tests are exercising this already more but it gets worse the more generic code the optimizer can’t specialize

@taylorswift has a lot of experience with this, but IIRC the optimizer also has difficulty specializing through generics.

[hassila (Joakim Hassila)]

That’s an excellent point.

Also, just o be clear, it’s not really “my” tests, I just adopted @johnno1962 tests to try to get some less wild measurements as I was curious. (Some of the results are a bit surprising!)

[taylorswift]

@johnno1962

If I understand "using a blackhole" turns off the optimiser and inlining.

blackholes are completely orthogonal to inlining, and they don't turn off the optimizer, they merely simulate a cross-module function call. one of the reasons inlining can backfire is by turning one blackhole invocation into several constituent blackhole invocations.

usually the purpose of inlining is to make APIs immune to the cross-module function call problem, if something is not @inlinable it is already a black hole from the perspective of the caller. we generally do not want to make everything @inlinable, which is why blackhole testing is valuable.

[lukasa (Cory Benfield)]

Additionally, blackhole testing prevents the optimizer from observing that a computation is entirely unnecessary and optimizing it away altogether.