Chaque application créée avec l’application de bureau WebCatalog occupait jusqu’à présent environ 320 Mo d’espace disque sur macOS. Ce n’est pas inhabituel pour une application fondée sur Electron, mais WebCatalog est conçu pour les personnes qui utilisent de nombreuses applications web comme applications de bureau. Avec dix applications installées, elles pouvaient occuper plus de 3 Go, alors que la plupart des données qu’elles contenaient étaient exactement les mêmes.
Nous avons récemment modifié la façon dont l’application de bureau WebCatalog crée les applications sur macOS. La première application utilise désormais environ 340 Mo d’espace disque physique, ce qui comprend une copie préparée du moteur d’application conservée localement. Ensuite, chaque application supplémentaire n’ajoute généralement que 1 à 2 Mo d’espace disque réellement utilisé. Lors de nos tests, l’espace occupé par dix applications est passé de plus de 3 Go à environ 360 Mo.
Pour cela, nous avons utilisé une fonctionnalité déjà intégrée à macOS : les clones APFS. Le défi ne consistait pas simplement à cloner des fichiers, mais à faire fonctionner le clonage tout en préservant l’indépendance de chaque application, la validité de sa signature de code et son équivalence fonctionnelle avec une application créée selon l’ancien procédé.
Pourquoi chaque application occupait 320 Mo supplémentaires
L’application de bureau WebCatalog transforme des sites web en applications de bureau autonomes. Chaque application créée fonctionne avec Photon, notre moteur d’application fondé sur Electron. Sur macOS, chacune est un paquet .app ordinaire contenant Electron (Chromium et Node.js), Photon et les fichiers propres à cette application.
Prenons deux applications, Slack et Discord. Leurs noms, icônes, identifiants de paquet et configurations diffèrent, mais le volumineux framework Electron et la majeure partie de Photon sont identiques.
Jusqu’à présent, chaque application était créée sous forme d’une copie entièrement distincte.
Slack.app
Electron
Photon
Fichiers propres à Slack
Discord.app
Electron
Photon
Fichiers propres à Discord
Le framework Electron et Photon pouvaient être identiques octet pour octet dans les deux applications, mais macOS stockait tout de même une nouvelle copie physique pour chacune. Dix applications représentaient donc approximativement dix copies d’un paquet applicatif de 320 Mo presque identique.
Cette architecture avait toutefois une propriété que nous voulions préserver : chaque application était entièrement indépendante. La suppression de l’une ne pouvait pas affecter les autres, et les applications installées n’avaient pas besoin que l’application de bureau WebCatalog reste présente sur le système.
Ce que nous voulions éliminer, c’était la duplication inutile des données sous-jacentes.
APFS offrait déjà le mécanisme dont nous avions besoin
Les Mac modernes utilisent APFS, le système de fichiers d’Apple. APFS prend en charge le clonage, un mécanisme de copie sur écriture qui permet à deux fichiers indépendants de partager les mêmes données physiques jusqu’à ce que l’un d’eux soit modifié.
Imaginez que vous copiez un fichier de 300 Mo. Avec une copie classique, macOS écrit 300 Mo supplémentaires sur le disque : les deux fichiers occupent donc environ 600 Mo au total.
Avec un clone APFS, le nouveau fichier a toujours l’apparence et le comportement d’un fichier complet de 300 Mo, mais il pointe initialement vers les mêmes blocs physiques que l’original.
Fichier A ─────┐
├── blocs physiques partagés
Fichier B ─────┘
Si une partie du fichier B change ensuite, APFS n’écrit de nouveaux blocs que pour les données modifiées. Tout ce qui reste identique peut continuer à partager les blocs d’origine.
Fichier A ───────── blocs partagés
Fichier B ───────── blocs partagés
└──────── blocs modifiés
Du point de vue de l’application, les fichiers A et B sont distincts. Du point de vue du SSD, les données identiques n’ont besoin d’être stockées qu’une seule fois.
C’est presque exactement le fonctionnement qu’il nous fallait.
Créer des applications à partir d’une base commune
L’application de bureau WebCatalog prépare désormais une base pour chaque combinaison de versions d’Electron et de Photon. L’application de base Photon contient les éléments identiques d’une application à l’autre, notamment Electron, Photon, la structure du framework et les signatures communes.
Lorsque l’application de bureau crée une autre application avec les mêmes versions, elle n’extrait et ne construit plus une nouvelle copie complète à partir de zéro. Elle crée à la place un clone APFS de l’application de base Photon, puis ne personnalise que les éléments qui doivent être différents.
Il s’agit notamment du nom et de l’icône de l’application, de l’identifiant de paquet, des paramètres, des noms des exécutables, de l’identifiant de build et d’autres métadonnées propres à l’application.
Comme la majeure partie du paquet reste inchangée, APFS continue de partager les blocs physiques contenant Electron et Photon. Seule la quantité relativement faible de données propres à l’application occupe de l’espace supplémentaire.
Pourquoi ne pas simplement partager Electron ?
Une approche plus évidente consisterait à installer Electron une seule fois et à faire pointer toutes les applications vers cette installation.
Nous l’avons envisagée, mais elle changerait fondamentalement le modèle de fiabilité. Si l’installation partagée d’Electron disparaissait, toutes les applications qui en dépendent pourraient cesser de fonctionner. Un outil de nettoyage du cache pourrait la supprimer, tout comme la désinstallation de l’application de bureau WebCatalog ; déplacer ou restaurer une application individuelle deviendrait également plus compliqué.
Il faudrait aussi suivre les versions de l’environnement d’exécution dont dépendent les applications installées afin de pouvoir supprimer les anciennes versions sans risque.
La signature de code de macOS pose un autre problème. Une vérification stricte de la signature rejette les liens symboliques qui pointent hors du paquet applicatif.
Les clones APFS nous apportent les avantages du partage sans introduire cette dépendance. Les applications installées peuvent partager des blocs physiques sur le disque tout en restant des paquets applicatifs complets et indépendants.
Supprimer l’application de base Photon ne casse pas les applications créées à partir d’elle. Supprimer une application installée n’affecte pas les autres. Le système de fichiers gère le partage, tandis que l’architecture des applications reste indépendante.
La signature de code a failli annuler les économies d’espace
Cloner l’application ne résolvait qu’une partie du problème. Les applications macOS doivent aussi être signées.
Notre ancien processus de création signait de nouveau en profondeur chaque paquet applicatif après sa personnalisation. Avec une copie classique, cela ne pose pas de problème. Mais avec le stockage par copie sur écriture, la modification d’un gros fichier binaire peut amener APFS à lui allouer de nouveaux blocs physiques.
Pendant le développement, nous avons mesuré qu’une nouvelle signature du framework Electron ajoutait environ 194 Mo de stockage physique par application. Nous avions réussi à éviter de copier Electron lors de la création de l’application, pour finalement en dupliquer une grande partie au moment de la signature.
Le processus de signature devait donc lui aussi changer.
Le gros framework commun est désormais signé au sein de l’application de base Photon. Lorsque l’application de bureau clone cette base, nous évitons de modifier ces gros fichiers binaires partagés et ne signons de nouveau que les éléments plus petits qui doivent effectivement différer d’une application à l’autre.
Une fois l’application terminée, nous effectuons une vérification stricte de la signature du paquet final pour nous assurer que tout reste valide.
Nous conservons ainsi à la fois les garanties offertes par la signature de code de macOS et les économies d’espace permises par APFS.
Quand demander à Node.js de cloner ne produisait pas de clone
Un autre problème inattendu s’est présenté : l’opération de clonage elle-même.
Node.js propose des options de copie destinées à demander un fonctionnement par copie sur écriture, notamment COPYFILE_FICLONE et COPYFILE_FICLONE_FORCE. Sur le papier, ces API semblaient correspondre exactement à ce dont nous avions besoin.
Lors de nos tests avec Node.js 24, nous avons copié la même application Electron de 288 Mo de plusieurs manières, puis mesuré l’espace disque physique supplémentaire occupé par chaque opération :
fs.cpSync +288 Mo
fs.cpSync + COPYFILE_FICLONE +288 Mo
fs.cpSync + COPYFILE_FICLONE_FORCE +288 Mo
/bin/cp -c -R ~0 Mo
Dans notre test, les deux modes de clonage de Node.js ont tout de même produit une copie physique complète. Même la variante FORCE n’a signalé aucune erreur lorsque le clonage attendu ne s’est pas produit.
La commande native cp -c de macOS s’est comportée comme prévu : l’application de bureau WebCatalog utilise donc directement ce mécanisme.
Cela nous a également rappelé qu’il faut vérifier les optimisations du système de fichiers en mesurant le système de fichiers lui-même. Appeler une API qui demande une copie sur écriture ne signifie pas nécessairement que les fichiers obtenus partagent effectivement le même espace de stockage physique.
Faire en sorte que l’optimisation puisse échouer sans conséquence
Économiser de l’espace disque est une optimisation. Réussir l’installation d’une application est indispensable.
Nous avons conçu le nouveau processus de sorte qu’un échec du clonage n’empêche pas l’installation. Si la préparation de l’application de base Photon échoue, si la base mise en cache est endommagée, si le clonage échoue ou si la vérification de la signature ne réussit pas, l’application de bureau revient à l’ancien processus, avec une extraction et une signature complètes.
Dans le pire des cas, l’espace disque utilisé est donc le même qu’avant : l’installation n’échoue pas.
Nous avons aussi dû tenir compte des opérations simultanées. Une application de base Photon est d’abord préparée dans un répertoire temporaire et n’est déplacée vers son emplacement définitif qu’une fois terminée. Ainsi, si deux applications sont créées en même temps, aucune ne risque de tomber sur une base inachevée.
Les anciennes bases peuvent elles aussi être supprimées sans risque. Un clone APFS installé n’a pas besoin que la base d’origine continue d’exister. Si celle-ci est supprimée, le clone conserve les blocs physiques qu’il utilise encore.
Cela fonctionne sur APFS, le système de fichiers par défaut de tous les Mac modernes. Si vos applications se trouvent sur un disque qui ne permet pas le clonage, comme un disque externe HFS+ ou exFAT, l’application de bureau WebCatalog revient à une copie classique. Les applications fonctionnent alors comme avant, mais sans économie d’espace. Rien ne change pour le moment sous Windows et Linux.
Taille logique et taille physique ne sont pas la même chose
Un effet secondaire un peu déroutant est que le Finder peut toujours indiquer qu’une application occupe environ 320 Mo.
Ce chiffre correspond à la taille logique de l’application. Celle-ci contient réellement l’équivalent d’environ 320 Mo de fichiers et, si ces fichiers étaient copiés ailleurs sans clonage, c’est approximativement la quantité de données qu’il faudrait écrire.
Ce qui a changé, c’est la taille physique, c’est-à-dire le nombre de blocs distincts que ces fichiers occupent réellement sur le disque.
Si deux applications contiennent le même framework de 300 Mo et qu’APFS leur permet de partager les mêmes blocs sous-jacents, chacune peut avoir une taille logique de 300 Mo alors que la seconde n’ajoute presque aucune donnée physique.
La fenêtre Lire les informations du Finder et des outils comme du ne rendent pas nécessairement ce partage visible. Les économies se constatent surtout dans l’espace libre qui reste effectivement sur le disque.
Nous l’avons vérifié avec sept applications réelles : Discord, Facebook, Instagram, Messenger, TikTok et deux applications personnalisées. Créées de cette façon, elles ont permis d’économiser environ 1,9 Go d’espace disque par rapport à l’ancien processus.
Nous avons également examiné les emplacements physiques sous-jacents sur le disque et confirmé que les applications partageaient leurs données Electron et Photon communes au niveau des blocs. Une application créée selon l’ancien processus ne partageait aucun de ces blocs, ce qui nous a fourni un point de comparaison utile.
Le résultat
Pour une personne qui ne crée qu’une seule application avec l’application de bureau WebCatalog, la différence est faible. La première application occupe même un peu plus d’espace qu’avant, car l’application de bureau conserve aussi l’application de base Photon utilisée pour créer les clones suivants.
L’avantage augmente ensuite rapidement.
Avant
1 application ~320 Mo
10 applications >3 Go
Avec le clonage APFS :
Après
1 application ~340 Mo
10 applications ~360 Mo
Une fois la base initiale créée, chaque application supplémentaire n’ajoute généralement que 1 à 2 Mo d’espace disque physique utilisé.
L’essentiel est que nous y sommes parvenus sans introduire de dépendance à un environnement d’exécution partagé. Chaque application reste une application macOS ordinaire et autonome, tandis qu’APFS ne stocke qu’une seule fois les données Electron et Photon identiques. Avec une dizaine d’applications installées, cela peut réduire l’espace disque réellement utilisé d’un facteur supérieur à huit.
Cette fonctionnalité est disponible dans la dernière version de l’application de bureau WebCatalog sur macOS. Vous n’avez rien à activer : les nouvelles applications l’utilisent automatiquement, et celles que vous possédez déjà occuperont moins d’espace lors de leur prochaine mise à jour.