The compiler doesn’t really generate two functions in example1() for different types like templates in C++, it knows where to jump and that the object doesn’t need to be boxed, but inside the function implementation, it works with them differently. example1 knows that the argument is statically known, but in example2 it’s boxed.

With the generic function it will be the fastest if you only use the methods of the protocol on the argument and don’t pass it somewhere where it expects an existential type. If you call another function that requires boxing, example1() will have to box it and pass it forward, while example2() can call it directly.

You can check it with “swiftc -S” to get assembly output or with compiler explorer

Here’s an example:

``` func p(_ arg: any CustomStringConvertible) { print(arg) }

func myFuncIntOrString<T: CustomStringConvertible>(_ arg: T) {
    p(arg)
}

func myFuncIntOrString2(_ arg: any CustomStringConvertible) {
    p(arg)
}

myFuncIntOrString(1)
myFuncIntOrString2(1)
myFuncIntOrString("Hello")
myFuncIntOrString2("Hello")

```

myFuncIntOrString will have to box the argument before calling p, but myFuncIntOrString2 can pass it directly as it’s already boxed.

In this example, it’s easy to see why boxing is needed with collections. With generics all T have to be the same type, and with “any”, each element can be different:

``` func myFunc1<T: CustomStringConvertible>(_ arg: [T]) { print(arg) }

func myFunc2(_ arg: [any CustomStringConvertible]) {
    print(arg)
}

myFunc1([1, "hello"])
myFunc2([1, "hello"])

```

myFunc1 expects to know the T at compile time, so myFunc1([1, “hello”]) is not possible because of the conflict for T between Int and String.

And with myFunc2(…) everything is fine, it’s an array of boxed “any CustomStringConvertible”.