/ Team iOS

You should file a Radar

Remplir un radar est souvent considéré comme une perte de temps. Cependant, la dernière fois que j'en ai rempli un, cela m’a pris 20 minutes (cas de tests inclus) et grâce à lui, les ingénieurs d'Apple ont réduit le temps de build de mon projet de plus de 50%.

Comment Apple a reduit mon temps de build de moitié !

Ce petit billet d’humeur c’est pour vous raconter une histoire qui m’est arrivée récemment. Je follow sur Twitter pas mal de devs d’Apple et il y a quelques semaines l'un d'entre eux, Slava Pestov qui travaille sur la toolchain Swift (la toolchain c’est l’ensemble des outils nécessaires pour compiler du code Swift), demande si des gens constatent des différences fortes entre les temps de compilation en mode Whole Module Optimisation (WMO) et avec WMO désactivé.

C'est précisément notre cas, le temps de compilation moyen de notre app étant de :

  • 7 min 41s en mode non WMO
  • 3 min 44s en mode WMO

Ces tests ont été effectués sur un MacBook Pro 2017 avec les specs au max. Pour en savoir plus sur notre projet je vous conseille ce post Swift @ Pagejaunes. Pour la mesure j'ai fait plusieurs clean build dans chaque configuration puis une moyenne (xcode-build-duration).

C'est méga lent et ça nous handicape pas mal pendant notre travail. Je lui ai donné mes temps de compilation et lui ai demandé si ceux-ci entraient dans sa définition de "lent". J’ai ouvert un radar dans la foulée avec le code de notre application sans les mots de passe de production (au cas où... on ne sait jamais...). De toute façon les radars sont privés entre Apple et ceux qui les remplissent et Apple n’en divulgue pas le contenu. Le revers de la médaille c’est que les radars peuvent sembler obscures et peu pratiques.

bug-reporter-96x96_2x

Toutes les conversations ne sont pas visibles dans ce post dû aux limitations de Twitter.

Il a répondu à mon tweet au bout de quelques jours, m’a remercié et indiqué ne pas avoir le temps ces jours-ci de regarder mais qu’il le ferait prochainement. Quelques jours après, il a démarré l’analyse et détecté 5 bugs (4 bugs + 1 bug) dans la toolchains. Il a ouvert d’autres radars afin de suivre le fixing de ces bugs.

Je suis avec une grande attention ce qui ce passe sur les mailings list ainsi que sur le Github Swift et même si je ne comprends pas tout, je vois qui fait quoi, ce sur quoi ils sont focus et comment ils résolvent leur problèmes (les commits et le code sont généralement trés bien documentés).
Apple travaille fortement pour résoudre sa dette technique sur la toolchain ainsi que sur les problèmes de temps de compilation, Graydon Hoare qui a créé le language rust fait partie des gens qui sont à fond sur le sujet.

Graydon a écrit un post très clair sur ce sujet, où ils en sont précisément et vers où ils veulent aller.

“Slava Pestov is going wild reducing Swift compilation times and improving runtime performance. He opened a draft pull request with what Joe Groff calls “a pretty significant optimization for unspecialized Swift code,” as well as a work-in-progress pull request that he notes will crack down on some redundant validation the Swift compiler performs.” [1]

J’ai remarqué au cours des dernières semaines plusieurs PR de Slava où il fait des fix / cleanup associés à des régressions et de ce que je comprends de son message de commit c’est sûrement dû à ce que je lui ai envoyé.

Quelques temps après son premier tweet, Slava poste à nouveau un message parlant de sa satisfaction d’avoir fait gagner deux minutes de temps de compilation à notre projet. Puis quelques heures après, à nouveau, un autre tweet où il annonce qu’il l'a encore réduit de 1 min 30s.

Ensuite il semble qu’il n'ait plus trop d’idées de fix pour réduire ce temps de build mais qu'avec d’autres devs ils travaillent sur une approche plus globale et profonde afin de réduire les temps de compilation.

Je l’ai donc remercié pour son taff et son implication.

Conclusion

Au final j’ai entendu beaucoup d’Apple bashing (fixradarorgtfo.com) associé à la gestion des radars. Mais je sais aussi que beaucoup de développeurs internes d’Apple sont accessibles sur Twitter et qu’ils travaillent sur plein de projets différents : de Safari à la toolchain Swift en passant par le Playground ou encore Xcode. Remplir un radar peut nous paraître une perte de temps parce que l'on a pas de visibilité sur comment cela est traité en interne. De tout ce que j'ai lu et entendu, le radar est ce qu’ils utilisent le plus en interne afin de suivre leurs projets / sujets. Cela sert également à la priorisation et si vous n'en faites pas, Apple ne pourra pas officiellement vous aider. Demander de l’aide directement à un de leur devs pourait donc bien être plus efficace à condition que la team qui les traite de l’autre côté soit réactive/attentive.

Au final, Slava a permis de réduire le temps de compilation de l’app en mode non WMO d'environ 54%, passant de 6 min 30s à 3 min 🤯.

Le fait qu'Apple travaille en open source est une super opportunité pour avoir du support et aider à améliorer les choses.

Si vous voulez en savoir plus sur le sujet des performances de compilation je vous conseille ces liens GitHub CompilerPerformance et Optimizing-Swift-Build-Times.

One more thing

Dans un monde idéal j’aimerais qu'Apple propose une compatibility suite pour les app iOS un peu comme pour la swift compatibility suite pour les libs swift. Le but serait de pouvoir leur passer de façon sécurisée du code de nos projets (issus du terrain quoi) afin qu’ils puissent tester du code créé par des gens qui ont utilisé leur outils de plein de façons différentes et de peut-être mieux debugger leur toolchain.

C'était mon premier post 😁 Merci de l'avoir lu.


  1. https://swiftweekly.github.io/issue-95/ ↩︎