The Surprising Cost of Protocol Conformances in Swift
emergetools.com
The Surprising Cost of Protocol Conformances in Swift
1–10 of 13 posts
Re: The Surprising Cost of Protocol Conformances in Swift
#2 > The concept behind zconform is to eagerly load all possible protocol conformances and store them in a map keyed by the protocol’s address in memory.
Re: The Surprising Cost of Protocol Conformances in Swift
#3> The concept behind zconform is to eagerly load all possible protocol conformances and store them in a map keyed by the protocol’s address in memory. if it works well in most scenarios, couldn't this just be implemented directly in the swift runtime at some point?
Maybe, but Swift is intentionally lazy in lots of ways (globals aren't initialized until the first access, for example).
The trade-off of zconform's approach is that dynamic linking is slowed down by needing to eagerly identify all protocol conformances whenever an image is loaded (including conformances which are never even cast). It does make the performance of dynamic casting more deterministic, but it would slow down (for example) app launch by eagerly pre-caching things which might never be queried.
I'd expect that the response from the Swift team would be to avoid dynamic casting in performance-critical code, rather than pessimize link-time.
[Edit, to clarify why the cache needs to be rebuilt when libraries are loaded]: Swift protocols have a feature called retroactive conformance, which allows apps and libraries to add protocol conformance to types they don't own. So, any library that gets loaded could add a protocol to a type. It's a really powerful feature, but has some unfortunate side-effects...
Re: The Surprising Cost of Protocol Conformances in Swift
#4This is about the casting cost specifically, not the direct cost of using a protocol as interface, which itself has some annoying performance characteristics
Re: The Surprising Cost of Protocol Conformances in Swift
#5I feels like I must be missing something. 3ms is extremely slow. Surely it should be 3us, no? What’s it doing that is so slow?
Re: The Surprising Cost of Protocol Conformances in Swift
#6Swift has a real performance problem, it doesn't seem competitive with other "systems languages"
Is the goal to make it faster later? What can be done to get closer to that goal?
Re: The Surprising Cost of Protocol Conformances in Swift
#7Swift has a real performance problem, it doesn't seem competitive with other "systems languages" Is the goal to make it faster later? What can be done to get closer to that goal?
Swift is quite fast as an app programming language. I’ve never understood why anyone could consider it a systems programming language with a straight face. But to say that it has a “real performance problem” is a bit of an exaggeration. Compared to the many other languages out there, it’s faster than most.
Re: The Surprising Cost of Protocol Conformances in Swift
#8I feels like I must be missing something. 3ms is extremely slow. Surely it should be 3us, no? What’s it doing that is so slow?
Function names like "_dyld_find_protocol_conformance" seem to indicate that DLLs might need to be accessed, and my (entirely subjective) impression is that this general area seems to have become a lot slower in recent macOS versions, at least when system DLLs are involved.
Re: The Surprising Cost of Protocol Conformances in Swift
#9Swift has a real performance problem, it doesn't seem competitive with other "systems languages" Is the goal to make it faster later? What can be done to get closer to that goal?
Swift is quite fast as an app programming language. I’ve never understood why anyone could consider it a systems programming language with a straight face. But to say that it has a “real performance problem” is a bit of an exaggeration. Compared to the many other languages out there, it’s faster than most.
Probably because that is one of the states goals as voiced by the languages creator
Re: The Surprising Cost of Protocol Conformances in Swift
#10Earlier quoted context omitted.
Swift is quite fast as an app programming language. I’ve never understood why anyone could consider it a systems programming language with a straight face. But to say that it has a “real performance problem” is a bit of an exaggeration. Compared to the many other languages out there, it’s faster than most.
Probably because that is one of the states goals as voiced by the languages creator
That was a long time ago, I thought. The word "systems" was removed from the swift website years ago when it was clear that it did not really have that priority.