Si vous avez un PC Intel sous Linux et que vous avez toujours eu l'impression que Windows tirait mieux parti de votre processeur, vous n'étiez pas forcément paranoïaque. Sur certains processeurs récents, le noyau Linux gérait les fréquences CPU de manière conservatrice, ce qui pouvait limiter les performances dans certains cas. Bonne nouvelle : ça vient de changer.

En effet, le kernel 6.18, annoncé par Linus Torvalds le 30 novembre 2025, embarque un patch qui lève une restriction du pilote intel_pstate. Concrètement, le driver peut maintenant activer les états de performance matériels (HWP) dans des cas où il refusait de le faire auparavant.

Le truc technique, c'est que jusqu'ici, le pilote intel_pstate refusait d'activer HWP (Hardware P-States) si le processeur ne supportait pas EPP (Energy Performance Preference). Rafael J. Wysocki, mainteneur du sous-système power management, a modifié cette logique : désormais, si le bit DEC (Dynamic Efficiency Control) est activé dans le registre MSR_IA32_POWER_CTL, HWP peut fonctionner même sans EPP.

C'est important, parce que certains processeurs Intel récents intègrent cette fonctionnalité DEC mais pas forcément un support EPP complet. Du coup, avant ce patch, le driver désactivait HWP par prudence sur ces plateformes. Le patch cible notamment les processeurs Panther Lake.

Je sais, c'est beaucoup de jargon technique et je pense que j'en ai perdu pas mal d'entre vous, mais c'est chouette pour les gamers et les utilisateurs de distributions Linux orientées gaming comme Bazzite .

Sur les plateformes concernées, les applications mono-thread et les jeux qui dépendent des fréquences CPU élevées pourraient en bénéficier, même si l'impact réel dépendra de votre configuration matérielle et des réglages de votre distribution.

Bref, Linux rattrape enfin son retard sur Windows en matière de gestion des fréquences Intel. C'était pas trop tôt.

Source

Demat' iNal,

On (merci Sylvestre !) m'a fait découvrir un utilitaire, hyperfine ¹, qui a changé mon quotidien, et ne cesse de me surprendre.

hyperfine, c'est un outil "gros grain" pour faire de la mesure de performance. Ceux qui sont habitués au module standard Python timeit ² y retrouveront des principes similaires, mais adaptés au shell.

Sous sa forme la plus simple, hyperfine s'utilise de la manière suivante (ici pour mesurer combien de temps clang met à parser le fichier d'en-tête standard stdio.h):

% hyperfine 'echo "#include <stdio.h>"| clang -xc -fsyntax-only -' 
Benchmark 1: echo "#include <stdio.h>"| clang -xc -fsyntax-only -
  Time (mean ± σ):      21.6 ms ±   1.0 ms    [User: 11.5 ms, System: 10.0 ms]
  Range (min … max):    20.3 ms …  25.6 ms    112 runs

Quel plaisir d'avoir accès à autant d'information si rapidement. Les statistiques permettent d'apprécier grossièrement la reproductibilité, et donc la fiabilité, de l'expérience.

Si l'expérience a de gros problèmes de reproductibilité, hyperfine nous en avertit (ici on for ce le passage par un cache, via sccache ³:

% hyperfine 'echo "#include <stdio.h>"| sccache clang -xc -fsyntax-only -'  
Benchmark 1: echo "#include <stdio.h>"| sccache clang -xc -fsyntax-only -
  Time (mean ± σ):      26.4 ms ±   4.4 ms    [User: 12.7 ms, System: 15.4 ms]
  Range (min … max):    25.1 ms …  56.9 ms    51 runs

  Warning: The first benchmarking run for this command was significantly slower than the rest (56.9 ms). This could be caused by (filesystem) caches that were not filled until after the first run. You should consider using the '--warmup' option to fill those caches before the actual benchmark. Alternatively, use the '--prepare' option to clear the caches before each timing run.

Et il nous suggère même de chauffer le cache, ou d'avoir une étape de préparation (non mesurée donc) avant de commencer l'expérimentation.

Mais la fonctionnalité qui m'a le plus bluffé, c'est la possibilité d'automatiser en un one-liner un petit protocole expérimental qui m'est très courant : vérifier si le commit sur lequel je viens de finir de travailler améliore ou pas les performances. Cas pratique :

Bossant sur le bug 2003034 lié au système de test de Firefox, j'ai crée une branche bug/2003034, fait mon travail de dev standard, commit du résultat, puis commande suivante (merci Julien o/)

% hyperfine -L branch bug/2003034^,bug/2003034 -s 'git checkout {branch}' 'TASKGRAPH_SERIAL=1 ./mach taskgraph full'
[...]

koikekès ? Le drapeau -L permet de définir des paramètres d'expérience (ici le paramètre branch) et de lui assigner plusieurs valeurs, une par expérience donc (ici bug/2003034^ puis bug/2003034). Le drapeau -s fournit un setup code, un code à exécuter avant chaque expérience. Et dans ce code les paramètres définit par -L sont substitués, /à la/ f-string. Le dernier argument est utilisé pour lancer chacune des expériences.

Au final on obtient une sortie de ce type :

% hyperfine -L branch bug/2003034^,bug/2003034 -w1 -r5 -s 'git checkout {branch}' 'TASKGRAPH_SERIAL=1 ./mach taskgraph full'
Benchmark 1: TASKGRAPH_SERIAL=1 ./mach taskgraph full (branch = bug/2003034^)
  Time (mean ± σ):     68.209 s ±  0.639 s    [User: 66.996 s, System: 4.318 s]
  Range (min … max):   67.370 s … 69.035 s    5 runs

Benchmark 2: TASKGRAPH_SERIAL=1 ./mach taskgraph full (branch = bug/2003034)
  Time (mean ± σ):     67.463 s ±  0.375 s    [User: 66.367 s, System: 4.272 s]
  Range (min … max):   66.807 s … 67.733 s    5 runs

Summary
  TASKGRAPH_SERIAL=1 ./mach taskgraph full (branch = bug/2003034) ran
    1.01 ± 0.01 times faster than TASKGRAPH_SERIAL=1 ./mach taskgraph full (branch = bug/2003034^)

Chaque expérience a son petit paragraphe, et on a même un récapitulatif de l'expérience. Génial.

Ce n'est pas de la grande algorithmique, mais j'y vois un soucis du détail qu'il faut apprécier : un outil qui répond à un besoin, qui le fait bien, et qui nous assiste jusque dans les détails, youpi. Allez, je retourne lire la page man !

PS:
Je t'écris moins souvent, tu m'en excuseras peut-être en sachant que j'entretiens une correspondance suivie avec ton comparse qui a défaut d'être en or, est en diamant. Un seul ⁴ épisode des codes fantastiques (et où les trouver) est passé en public pour l'année 2025. À défaut il y en a pas mal des années précédentes ⁵.

Commentaires : voir le flux Atom ouvrir dans le navigateur

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. En attendant, jetez un œil à Ripcord et Stoat pour ceux qui veulent un truc mieux.

Source

WordPress, c’est bien. Mais WordPress qui injecte des scripts d’emojis, des styles Gutenberg, des shortlinks et 47 autres trucs dont vous n’avez pas besoin dans chaque page de votre site… c’est moins bien évidemment. Heureusement, Terence Eden, un dev qui en avait marre de voir son code source ressembler à un plat de spaghetti, a compilé une petite liste de tout ce qu’on peut virer .

Car WordPress a adopté une philosophie de type “Decisions, not options” (des décisions, pas des options) où en gros, au lieu de vous laisser choisir, ils décident pour vous de ce qui est bon pour vous. Un peu comme Macron ^^. Le problème c’est que leurs décisions incluent un tas de fonctionnalités dont la plupart des gens n’ont rien à faire 🥲.

Par exemple les emojis. J’sais pas si vous savez, mais WordPress charge un script de détection d’emojis et une feuille de style dédiée sur CHAQUE page de votre site. Pourquoi tant de haine ? Hé bien parce que si vous tapez :-) dans un article, WordPress veut le transformer en joli emoji. Sauf que si vous utilisez les vrais emojis Unicode (comme tout le monde en 2025), hé ce script ne sert à rien. Et il y a aussi le grand remplacement des emojis dans les flux RSS…. Bref, tout ça, ça dégage.

Ensuite y’a le formatage automatique avec wptexturize qui transforme vos guillemets droits en guillemets typographiques “comme ça”. Et mon préféré, capital_P_dangit qui remplace automatiquement “Wordpress” par “WordPress” avec le P majuscule. Oui, vous ne le saviez pas, mais WordPress corrige l’orthographe de son propre nom dans vos articles. Mais quelle bande de nazes ^^.

Gutenberg, l’éditeur de blocs que j’adore, injecte lui aussi ses styles globaux même si vous utilisez l’éditeur classique. Et c’est pareil pour les styles de la librairie de blocs et l’éditeur de widgets basé sur les blocs. Si vous êtes resté sur le Classic Editor comme beaucoup de gens, tout ça ne sert alors qu’à alourdir vos pages.

Côté métadonnées, WordPress ajoute aussi pleiiiiin de trucs dans le code de vos pages comme les shortlinks, le RSD (Real Simple Discovery, un truc d’il y a 20 ans), des liens vers les flux de commentaires, les liens JSON de l’API REST…

Aux chiottes toutes ces conneries !

Le script de Terence fait aussi sauter l’ajout automatique des tailles d’images (wp_img_tag_add_auto_sizes), les templates de pièces jointes, et les block hooks qui modifient votre contenu. L’idée c’est donc de reprendre le contrôle sur ce que WordPress génère, au lieu de le laisser décider tout seul.

Et grâce à son script, le site de Terence (sans Philippe) obtient d’excellents scores sur PageSpeed Insights , ce qui prouve que tout ce bloat n’est vraiment pas nécessaire. Son script PHP complet fait environ 190 lignes et il est dispo sur son GitLab , bien commenté pour que vous puissiez choisir ce que vous voulez garder ou virer.

Attention quand même, certaines de ces désactivations peuvent casser des fonctionnalités si vous les utilisez vraiment. Par exemple, si vous avez des plugins qui dépendent de l’API REST, la virer complètement serait une mauvaise idée. Même chose pour les blocks Gutenberg si vous utilisez cet éditeur. L’astuce c’est donc de tester chaque modification une par une et de voir ce qui se passe.

Amusez-vous bien et un grand merci à Terence !