Relative Performance of Existential Any

That actually exists for a long time as well: https://www.ensembles.io

2 Likes

For anyone stumbling across this in the future looking for concrete performance data, see: Is existential any a performance problem in Swift? – Augmented Code

For creating one million structs, the cost of existentials added 3ms vs generics. So the performance impact seems irrelevant at the application level.

I have another benchmark I was just looking at where it's 60% of the total runtime. It depends a lot on how you test.

4 Likes

Ooph. I’m curious to know the context of that result.

I chose to go the subclass route for my framework, but I hit a snag: #Predicate can’t work with multi-component KeyPaths. In my case, I gave the base ModelObject class an id: UUID property. That base class is intended to be abstract. Subclasses inherit the id property but then you can’t use that in a #Predicate, which is a non-starter.

(I realized this limitation only later, while implementing custom Predicate parsing via expression)

So I’m forced to choose the existential approach with protocols. If I understand all of the above correctly, this should result in essentially the same performance as subclassing because the protocol is constrained to AnyObject and that’s always a pointer, which is one word.

I only took a quick look at it, so don't put too much weight on this analysis, but it looks like what's happening is assignWithCopy for Int is ending up with an actual call to memcpy through the VWT, and it turns out call overhead is pretty significant when the actual operation being done is just one instruction.

2 Likes