片田舎のおっさん、 Swift Buildのダイアモンド問題解決の不具合修正PRを出すが、解決方法がキャッシュをしないようにすることであり、ビルド時間が伸びると言われてマージされないので高速化もする/swiftbuild

https://potatotips.connpass.com/event/400003/

Transcript

1. POTATOTIPS #96 片 田 舎 のおっさん、 Swift Buildのダイアモンド問題解決の不具合修正PR を出すが、解決方法がキャッシュをしないようにす ることであり、ビルド時間が伸びると言われてマー ジされないので高速化もする 片田舎のおっさんこと yimajo BIG 3 PR SQUAT 85kg, BENCH 80kg, DEADLIFT 110 kg
2. はなしの前提 落ち着く… 前提は良い —-集中
3. Appleプラットフォーム用のネイティブなビルドはSwift Buildを使う Xcode $ xcodebuild $ swift build OSS llbuild Swift Build アプリのバイナリ potatotips #96 Swift Compiler
4. 依存関係のダイアモンド問題について 大抵のビルドシステムは モジュールの依存関係がダイアモンド型になるとき、 2経路がそれぞれStaticでないなら、 依存先をDynamic Linkにする。 （逆に経路が両方Staticなら依存先はStatic App Static Feature A Dynamic Feature B Dynamic Dynamic のままでいい） 「ダイアモンド問題の解決」と言ったりする。 Common CommonはDynamic Linkにしないといけない potatotips #96
5. ダイアモンド問題の解決できていないなら？ もし、Feature AがStaticで、Feature BがDynamic App と固定されていて、CommonがそれぞれStaticとし てLinkされると… Static Feature A ビルド時にAppはFeatureA経由でCommonをStatic Link Dynamic Feature B Static Static で含んでいて、アプリ起動時にDynamic LinkでFeatureB 経由で別のCommonを呼び出してしまう。 これで、2つのCommonが1アプリに重複して存在してし Common Common まう。 potatotips #96 04
6. 解決した不具合と解決方法 落ち着く… 不具合解決は良い —-集中
7. Swift Buildの潜在的不具合 App Dynamic固定 Embedded Framework • Step1: top-levelなTargetからダイアモンド判定 • そしてそれを重複判定しないようにキャッシュ化 • キャッシュ化された子のTargetを判定から外す Dynamic判定 • Step2: その他TargetもDynamic判定 • -> 子が別のTargetから重複しているのに判定から外される Feature X Feature A • 例 判定から外す • Feature AがAppとEmbeddedFrameworkからリンク • Dynamic判定されるが、FeatureAの子Commonは判 定材料から無視される • FeatureXのCommonは2つあるので本来Dynamic判定 すべきだが、判定材料の対象として見つからない Common Common Commonは重複だがもう一方の Commonは存在しないものとさ れDynamic化されない potatotips #96
8. 不具合修正の解決: PR #1424 ワイ「キャッシュの数行を削除することで問題を解 決だ！Pull Request出す」 レビュアー「処理が指数関数的に遅くなるけど、 DFSアルゴリズムに書き換えることはどう思う？」 ワイ「…！」 potatotips #96
9. 不具合修正の解決: PR #1424 やったこと 1. 不具合が再現するプロジェクトを用意 2. 不具合の再現をテストコードとして用意し失敗を確認 • このテストが成功することを目指す 3. DFS（深さ優先探索）アルゴリズムを調べる • 型を作りそのメソッドにロジックを書く • テストコードを書いておく 4. 上記2種類のテストが成功するように 5. 再現プロジェクトでも不具合起きないようにする potatotips #96
10. 不具合修正の解決: PR #1424 思ったこと • しかし不具合解決と高速化を1つのPRでやりたくないん だけどその理由は差分がわけわからんことになるから • （そもそも既存コードがわけわからんすぎる） • PRの差分の読みづらさを許容するんかい • こちらはもっとやりたいようにコードを書く • フォーマットはこちらが読み易いようにもする potatotips #96
11. 不具合修正の解決: PR #1424 ワイ「DFS使ったしワイの作りやすいようにした わ！」 マージ potatotips #96
12. こんな感じを繰り返し現在8個PRを出して6個マージ済み potatotips #96
13. 片田舎のおっさん、 The Swift Programming Language グループの Member になる potatotips #96
14. 感想：マージまでにも学びがある 01 あきらかな問題でも修正と高速化を同じPRで扱うことになる これは自分のやり方と違うけど郷に入っては郷に従うのがいいと思う 02 具体的なアルゴリズムを指定されることがある 依存関係は逆から辿ることで分岐もないので正直議論しても良かったが私には言語力がない 03 1つのPRの変更は1コミットにまとめ、force pushしてって感じ おそらく、差分の読みやすさとかコミットログとか気にしていない？ 自分たちがずっと使っていくAppleの製品へ組み込まれるコード やる意味は大きい…みんなもやっていこう potatotips #96
15. 発表は以上です さらに知りたい人向けの内容 おまけ: 実態の違う同名の型が存在するとどうなる？ potatotips #96
16. 知らんのか？ potatotips #96
17. Feature AとBそれぞれからシングルトンを作成しようとすると それぞれ2つできる Feature A static let sharedな何か Feature B static let sharedな何か この例はCommonへのStatic Linkが2個だけど CommonへStatic LinkがN個かつDynamic LinkがM個という状況でもダメ potatotips #96
18. 2つの経路で取得したインスタンスのキャストが失敗する 2つの別々の経路から取得した型を比べようとすると 一致しないので `error as? Common.Failure` は失敗するし `do { } catch Common.Failure { }` も失敗する potatotips #96
19. リソースが2つあったら超無駄 potatotips #96 Feature A Commonのリソース Feature B Commonのリソース