{"id":34589,"date":"2021-12-31T15:39:59","date_gmt":"2021-12-31T20:39:59","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=34589"},"modified":"2023-02-16T16:11:43","modified_gmt":"2023-02-16T21:11:43","slug":"the-surprising-cost-of-protocol-conformances-in-swift","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/12\/31\/the-surprising-cost-of-protocol-conformances-in-swift\/","title":{"rendered":"The Surprising Cost of Checking Protocol Conformances in Swift"},"content":{"rendered":"

Noah Martin<\/a> (Hacker News<\/a>):<\/p>\n

\n

The entry point to our investigation is Mike Ash’s PR<\/a> which implements a 13x faster cache that was released in Swift 5.4.<\/p>\n

[…]<\/p>\n

We now see that the speed of protocol conformance lookups is dependent on the number of conformances in your app. This will be influenced by how many Swift libraries you link to, and how many conformances you include in your own code. otool -l Helix.app\/Helix | | grep _swift5_proto -A 4<\/code> tells us Uber’s app has a 411200 byte protocol conformance section. Each 4 bytes is a relative pointer so 411200 \/ 4 = 102,800 conformances.<\/p>\n

[…]<\/p>\n

One source of low hanging fruit that might be in your app is removing protocols that are used only for providing stub implementations in unit tests. These can be compiled out of release builds of the app to avoid them being included in runtime metadata.<\/p>\n

[…]<\/p>\n

Profiling your app using tools like Instruments or the Emerge startup time visualization can help you identify where conformance checks are most often used in your app. Then you can refactor code to avoid them entirely.<\/p>\n

[…]<\/p>\n

The concept behind zconform<\/a> is to eagerly load all possible protocol conformances and store them in a map keyed by the protocol’s address in memory.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n