La solution nulle de Discord à son problème de consommation de RAM
Discord a trouvé une solution radicale pour gérer son app de ses morts qui bouffe 4 Go de RAM sous Windows 11 (consommation ressentie : 4 millions de Go) : La redémarrer automatiquement quand elle dépasse ce seuil.
Les champions quoi ! Plutôt que de corriger les fuites mémoires, ils ont tout simplement décidé d’intégrer un auto-relaunch dans l’app en douce pour qu’elle se relance toutes les quelques heures.
Donc, si votre Discord a tourné pendant au moins 1 heure, que vous êtes inactif depuis 30 minutes (pas de souris/clavier), et que vous n’êtes pas en vocal ou en visio, l’app se redémarrera automatiquement dès qu’elle atteindra les 4 Go de conso mémoire.
Bien sûr Discord présente ça comme une solution temporaire pendant qu’ils bossent sur le vrai problème, mais je trouve ça marrant de normaliser ce bug en ajoutant une fonctionnalité qui le “contourne” bruyamment.
Le pire dans tout ça, c’est que le problème vient d’une connerie technique assez basique. L’app Discord utilise une bibliothèque appelée “systeminformation” qui appelle PowerShell avec des commandes comme Get-WmiObject Win32_logicaldisk juste pour récupérer des infos système basiques. Mais comme ils passent par Powershell
plutôt que d’utiliser les API natives
de Windows, ça bouffe de la RAM comme un gros porc.
Comme vous, je me demande pourquoi Discord ne refait pas son app avec un framework plus léger ? Hé bien c’est simple : ils sont coincés ! Parce Discord est bâti sur Electron, et Electron c’est un framework qui embarque un Chromium complet salade tomates oignons dans chaque application. Ça permet aux devs web de créer des apps desktop avec du JavaScript, du HTML et du CSS , mais le prix à payer c’est une app qui pèse 85 Mo à l’installation et bouffe 200-400 Mo de RAM au démarrage.
En théorie Electron permet de créer une app cross-platform facilement. C’est-à-dire d’avoir un seul code pour Windows, Mac et Linux. Mais dans les faits, Discord maintient quand même du code spécifique par plateforme pour les notifications, l’overlay gaming, les raccourcis système, etc. Bref, ils ont tous les inconvénients d’Electron (RAM, taille) sans vraiment profiter de l’avantage du “write once, run everywhere”.
C’est vrai que réécrire Discord en natif coûterait des millions. Faudrait refaire toute l’interface, toutes les fonctionnalités, tous les systèmes de plugins et de thèmes. Surtout que pendant ce temps, l’équipe actuelle continue d’ajouter des fonctionnalités sur leur usine à gaz, ce qui creuse encore plus la dette technique. C’est le sunk cost fallacy version logicielle… en gros, ils ont tellement investi dans Electron qu’ils ne peuvent plus reculer, même si repartir de zéro serait probablement moins coûteux sur le long terme.
Pourtant, des alternatives à Electron existent. Tauri est devenu le framework préféré des devs qui veulent de la performance … On est à 2-3 Mo d’installeur, 30-40 Mo de RAM au repos et il utilise Rust et le webview natif du système plutôt que d’embarquer Chromium. Les apps sont donc légères, rapides, et consomment 10 fois moins de ressources.
Y’a aussi Flutter, React Native Desktop, Qt… des frameworks qui produisent des apps vraiment natives avec des performances dignes de ce nom. Visual Studio Code démontre qu’Electron peut être performant si on l’optimise correctement, mais ça demande un boulot monstre et malheureusement, Discord n’a clairement pas envie de mettre les moyens.
Le vrai problème n’est donc pas technique, c’est économique, car pour 1 dev natif, y’a 8 devs web . Electron permet d’embaucher des devs JavaScript pas cher plutôt que des devs C++/Rust/Swift qui coûtent une blinde… donc, sacrifier la RAM des utilisateurs coûte moins cher que payer des ingénieurs système. Et comme les PC ont maintenant 16-32 Go de RAM, ils se disent que 4 Go pour du chat en ligne, c’est acceptable. Lol.
Bref, tout ça pour dire que Discord normalise le “patch-as-a-feature”, et j’imagine que demain Slack, Teams et tous les autres vont faire pareil.























