{"id":30589,"date":"2020-11-06T17:06:14","date_gmt":"2020-11-06T22:06:14","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=30589"},"modified":"2020-11-25T16:16:19","modified_gmt":"2020-11-25T21:16:19","slug":"slow-swift-compilation-of-boolean-comparisons","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/11\/06\/slow-swift-compilation-of-boolean-comparisons\/","title":{"rendered":"Slow Swift Compilation of Boolean Comparisons"},"content":{"rendered":"

DeskA<\/a>:<\/p>\n

Since we moved parts of our codebase to swift, our compile times have effectively quadrupled. Trying to combat this, we’ve used the function and expression debug time flags to figure out if there’s something to be saved by simplifying expressions.<\/p><\/blockquote>\n\n

Via Nick Lockwood<\/a>:<\/p>\n

\n

TIL writing<\/p>\n

if foo == false {}<\/pre>\n
Compiles dramatically more slowly in Swift than:<\/p>\n
if !foo {}<\/pre>\n<\/blockquote>\n\n
DeskA<\/a>:<\/p>\n
There are multiple instances of boolean comparisons being slow in our project. I can easily cut our overall compilation time by 10s by getting rid of explicit comparisons unfortunately<\/p><\/blockquote>\n\n
Xiaodi Wu<\/a>:<\/p>\n
In fact, it does not know that both sides are of type Bool<\/code>, because ==<\/code> can be implemented to compare heterogeneous types and false<\/code> can be any type that’s expressible by a Boolean literal. Therefore, it has to figure out every possible combination of implementations of ==<\/code> and types conforming to ExpressibleByBooleanLiteral<\/code> that is available for use here to see if it’s a better match.<\/p>\n
[…]<\/p>\n
For numeric types specifically, there is a hardcoded compiler shortcut to make compile times tolerable until a general solution is discovered. No such optimization is hardcoded for Boolean values because it’s not<\/em> idiomatic to write == true<\/code> and == false<\/code>.<\/p><\/blockquote>\n\n
Previously:<\/p>\n