Live data from Hacker News

The Surprising Cost of Protocol Conformances in Swift

emergetools.com

11–13 of 13 posts

Re: The Surprising Cost of Protocol Conformances in Swift

#11

I 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?

It’s ms, that slow because every protocol conformance in every dylib needs to be checked. When this gets to 100k+ like in many large apps it takes multiple milliseconds

Re: The Surprising Cost of Protocol Conformances in Swift

#12

> 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…

Building up the cache at launch/dynamic link time does have a performance hit of a few ms, but if you know it will save you many runtime checks it can be worth it. Definitely makes sense for the runtime to have the lazy behavior built in. Hopefully the dyld cache will help get the best of both solutions by persisting a cache across multiple launches.

Re: The Surprising Cost of Protocol Conformances in Swift

#13
post #10
post #9

Earlier quoted context omitted.

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.

> The goal of the Swift project is to create the best available language for uses ranging from systems programming, to mobile and desktop apps, scaling up to cloud services.

> Fast. Swift is intended as a replacement for C-based languages (C, C++, and Objective-C). As such, Swift must be comparable to those languages in performance for most tasks. Performance must also be predictable and consistent, not just fast in short bursts that require clean-up later. There are lots of languages with novel features — being fast is rare.

Those are literally the stated goals. It does not get more clear than saying "Swift is intended to be a replacement for C-based languages (C, C++)..."

[0]https://www.swift.org/about/

Post reply on HN