Le centre de contrôle de macOS utilise en permanence une partie de votre CPU
Depuis macOS Big Sur, Apple a ajouté une fonction dans la barre de menu de son système d'exploitation, le centre de contrôle. Et visiblement, cette petite fonction assez pratique a un impact sur le CPU en permanence. Commençons par une chose : ce n'est pas dramatique pour le moment et le centre de contrôle ne ralentit pas votre Mac, mais ce point montre que les API modernes ont parfois des défauts.
C'est Frank A. Krueger qui en a parlé le premier sur X, le centre de contrôle nécessite environ 1 % de CPU sur son Mac. Nous avons pu le vérifier sur deux Mac : sur un Mac mini M1, l'usage du CPU est entre 1 et 2 % en permanence et sur un Mac mini 2018, entre 0,5 et 1 %. La différence entre les deux vient probablement de l'architecture : comme les cœurs économiques de la puce M1 sont moins rapides que ceux du Core i5 d'Intel, l'occupation CPU est mécaniquement plus élevée.
Michael Tsai a compilé quelques retours sur ce sujet sur son blog, qui montrent une chose : Apple a choisi de développer le centre de contrôle avec SwiftUI, une API qui vient de fêter ses 5 ans. Et cette API, pensée au départ pour l'Apple Watch et les appareils mobiles, impose quelques contraintes. La principale, qui est problématique dans le cas présent, est que l'application rafraîchit l'interface et les données à afficher même quand le centre de contrôle est caché (c'est-à-dire la majorité du temps). C'est un comportement intéressant dans le cas d'un appareil mobile, pour une bonne réactivité, mais ce n'est pas nécessairement adapté à un usage fixe.
SwiftUI : 4 ans, c’est grand ?
Maintenant, pour revenir au point évoqué au début, est-ce un problème ? Dans le cas du centre de contrôle seul, non. L'utilisation CPU reste très faible (1 % d'un cœur basse consommation) et ne va pas avoir un impact visible sur les performances ou la consommation. Mais si beaucoup de développeurs se tournent vers SwiftUI avec le temps, ce qui n'est pas encore réellement le cas sur Mac, ce comportement pourrait devenir gênant avec le temps.
Heureusement que la plupart des développeurs se tournent vers Électron qui n’a pas ce problème. Ouf.
@fte
Je capte l'ironie 👍🏻😂
@fte
Rhah l’autre jour j’ai surpris WhatsApp à 4,7Go de RAM, j’ai Teams qui ne fait pas beaucoup mieux… J’en peux plus ! C’est plus que l’OS ! Ça ne sert à rien de passer son temps à augmenter la puissance et la RAM si on la gaspille avec autant d’enthousiasme ! Et je ne parle pas de mon MBP M2 Pro qui met toujours le même temps à démarrer que mon premier iMac 266 !
(Oui, c'est mon moment coup de gueule !)
@PetrusM
Normalement la dernière version de WhatsApp est maintenant une app catalyst et donc native.
@Baptiste_nv18
Ah oui, tiens. Mais du coup elle ne fait pas cette mise-à-jour seule, c'est pour ça que je ne l'avais pas... (Et en plus elle passe de la version 23.2341.XX à 23.19.86.... Allez comprendre...)
J'espère qu'il y aura la même pour Teams (et Signal, tant qu'à faire !).
[EDIT] A priori oui : https://clubigen.fr/macg/article/135735
@PetrusM
Miam ! C’est bon la petrus 🤤 😉
On entend plus trop Apple parler de ses langages ; du moins publiquement. Ça marche moins ou bien ? Ils n'ont rien de piquant à annoncer ?
Avant, ils évoquaient son évolution pendant les WWDC ("introducing... Swift 5.0 !") mais maintenant ça préfère annoncer des widgets sur macOS 😵
@ bhelden
> On entend plus trop Apple parler de ses langages
Le créateur de Swift a quitté le navire...
Pour moi Swift, c'est un beau cadeau empoisonné.
Swift, c'est le Visual Basic d'Apple bien mérité par les devs qui ont peur des pointeurs et maîtrisent mal la programmation orientée objet.
Exemple : J'ai découvert dans du code dans ma boite un truc qui était déclaré en struct dans un composant codé en C++ (C++ pour des performances maximales sur des algos maison, même sur de vieilles machines). Et ces structs étaient passées alègrement en paramètre et en retours de fonctions. Même des structs gérées par des API d'Apple étaient passées "sur la pile" et non pas par pointeur.
En Swift c'est une bonne pratique, mais pas en C ou C++ ! On n'échange sur la pile que des données de taille réduite, pas des structs !
Finalement, j'ai dû remplacer la struct (je devais faire en sorte qu'elle soit "partagée") en classe et modifié tous les appels pour passer des pointeurs... Ça a aussi facilité le nettoyage fait désormais "naturellement" dans le destructeur alors qu'ils avaient ajouté une fonction "release()" dans la struct pour "nettoyer" un buffer interne... Et cette fonction release() était appelée moult fois, comme dans le temps avec les retain/release. En passant à une classe, j'ai pu virer tous ces appels à la fonction release() de cette struct - et la virer elle même...
Moi j'appelle ça "les ravages de Swift".
@marc_os
Le créateur de Swift a quitté la navire c’est un peu fort quand on voit les évolutions du langage je trouve…
@ marc_os : « Moi j'appelle ça "les ravages de Swift". »
Moi je dis que je ne vois pas trop le rapport avec Swift puisqu’on est là dans du C++.
Si ces développeurs ont écrit ça de cette façon parce qu’ils n’avaient pas réalisé qu’ils étaient dans un autre langage que Swift, le problème n’est pas vraiment Swift, hein… 🙄
@ BeePotato
> le problème n’est pas vraiment Swift, hein
Précision : Ce code a été écrit par un aficionados du Swift qui applique des techniques qui sont correctes en Swift mais pas en C, C++ ou Obj-C.
@ marc_os : « Précision : Ce code a été écrit par un aficionados du Swift qui applique des techniques qui sont correctes en Swift mais pas en C, C++ ou Obj-C. »
C’est bien ce que je disais : le problème ne vient pas vraiment de Swift, mais de ces développeurs, qui transposent des habitudes d’un langage à l’autre sans se poser de questions.
@bhelden
Tu parles peut-être que de la Keynote inaugurale de la wwdc, mais même cette année Apple a communiqué sur des évolutions du langage et des frameworks. Donc non, ça marche toujours très bien. La différence est peut-être qu’il y a 5 ans les technos étaient moins matures/robustes et nécessitaient plus d’évangélisation pour favoriser l’adoption. Il y a aujourd’hui beaucoup plus de traction qu’à l’époque.
Rien de surprenant… SwiftUI est une hérésie sur Mac puisqu’il n’est pas du tout prévu pour cette plateforme… Comme résultat on se retrouve avec des apps mal optimisées et aux interfaces d’iOS (comme les Réglages Système).
Un élément d’interface comme le Centre de Contrôle qui se rafraîchit en permanence même quand il n’est pas affiché n’aurait jamais dû passer en production! Mais bon, le Contrôle Qualité s’est envolé chez Apple, tout comme la compétence. Ce qui compte aujourd’hui c’est iOS, ensuite on confie les autres plateformes aux stagiaires inexpérimentés qui se débrouillent dans un temps ultra limité et avec des frameworks qui ne sont pas optimisés pour la plateforme…
@mat16963
C'est l'impression que j'ai aussi.
Et encore plus avec le Vision Pro qui va sortir .. j'ai l'impression que depuis quelques années, il y a clairement moins de développeurs (et moins bons) sur les plateformes iOs et MacOS. Et qu'ils font le strict minimum..
@benjaminrousseau
Et oui coder ça se perd.
@TDBI
"Et oui coder ça se perd."
Pas tant que ça. C’est surtout que ce n’est pas rentable de coder pour macOS quand on peut coder pour iOS et que la compatibilité vient automatiquement avec peu d’efforts, ou que l’on peut coder avec les technologies web qui marchent partout. Plus personne ne commence des développements pour macOS natif, zéro intérêt.
@ fte
> Plus personne ne commence des développements pour macOS natif, zéro intérêt
Mais oui bien sûr.
Je me demande bien ce qu'on fait dans ma boite...
Avec ce genre de réflexion on se demande plus pourquoi des entreprises se permettent de sortir des jeux sur Mac qui ne sont pas optimisés.
@marc_os
"Mais oui bien sûr."
Yep.
"Je me demande bien ce qu'on fait dans ma boite..."
Souffrir inutilement ? Aussi, un cas particulier n’est pas la majorité.
"Avec ce genre de réflexion on se demande plus pourquoi des entreprises se permettent de sortir des jeux sur Mac qui ne sont pas optimisés."
Wow. Des entreprises ? Des jeux ? Des pluriels ? Tu vis dans un univers parallèle ?!
@ fte : « Aussi, un cas particulier n’est pas la majorité. »
En effet.
Il est cependant tout à fait suffisant pour rendre faux un « plus personne ». 😉
@BeePotato
"Il est cependant tout à fait suffisant pour rendre faux un « plus personne ». 😉"
C’est tellement vrai ! 😂
Je m’incline, tu m’as piégé.
-> Plus personne saine d’esprit. 😉
@ fte : « Je m’incline, tu m’as piégé. »
Moi ? Je n’ai piégé personne.
J’ai juste souligné l’erreur de généralisation abusive que tu avais (une nouvelle fois) commise.
@BeePotato
"une nouvelle fois"
Ah, ça c’est abusé. Je ne le fais que très rarement et par accident de langage, quand je force le trait pour souligner un point.
@ BeePotato
"Il est cependant tout à fait suffisant pour rendre faux un « plus personne »."
Le cas particulier est de la même manière tout à fait suffisant pour rendre faux un « tout le monde ».
@ claude72 : « Le cas particulier est de la même manière tout à fait suffisant pour rendre faux un « tout le monde ». »
En effet.
Mais je ne crois pas qu’on ait lu le moindre « tout le monde » dans ce fil de commentaires.
@ BeePotato
Je ne faisais que compléter ta remarque.
0,1% la plupart du temps ca monte à 6% juste quand on ouvre et c tout
macbook pro m2max
Imaginez 0,1% X tous les les processus qui tournent en arrière plan.....
@nicopulse
ca c deja le cas 😁
Bonjour à toutes et tous.
Quand je constate que myCanal utilise (sur mon iMac) seulement près de 5,3% du CPU (à peu près 225 Mo de mémoire) et que Safari par contre utilise à peu près 23% (8 onglets ouverts - 1,14 Go "juste" pour safari en ne comptant donc pas ce que consomme chaque onglet ouvert); je me dis qu'il n'y a pas que les applications "SwiftUI-sées" qui peuvent causer quelques déconvenues à la longue ^^
« C'est un comportement intéressant dans le cas d'un appareil mobile, pour une bonne réactivité »
Je ne vois pas pourquoi j’aurais besoin de moins de réactivité sur mac. D’ailleurs sur mobile si j’ai plus de réactivité ça doit nécessairement se faire au détriment de la batterie, ce qui est plus problématique sur mobile que sur desktop
C'est un rien plus compliqué. C'est pensé pour des appareils très limités en puissance qui peuvent prendre du temps pour récupérer les données et les afficher, alors qu'on attend une réponse directe.
On a moins le problème sur un Mac, dans le sens ou on a probablement une connexion permantente, plus rapide et un CPU des dizaines de fois plus performant. Donc un appareil capable de gérer ça sans latence visible... et sans s'en occuper périodiquement en arrière-plan.
> Apple a choisi de développer le centre de contrôle avec SwiftUI, une API qui vient de fêter ses 5 ans
À SwiftUI, la belle regression !
Inspiré de ReactJS semble-t-il, on n'utilise plus d'interface graphique pour définir son interface graphique, mais on code en Swift.
C'est comme si la modernité chez Apple consistait à faire des dessins vectoriels au format SVG non pas avec un éditeur graphique, mais uniquement avec du code. Ou comme si la "modernité" consistait à abandonner les Word, Pages, Xpress et compagnie pour faire coder la mise en page à la Markdown.
Font chier ces devs venant du web qui ont visiblement pris le pouvoir chez Apple. Entre les applications mal optimisées comme ce centre de contrôle et celles qui perdent des fonctions, en passant par le délire des Réglages Système dignes de Windows, ça commence à me saouler.
@ marc_os :
Comme tu l’as sûrement déjà remarqué, je ne partage pas ton opinion au sujet de Swift.
Mais concernant SwiftUI, en revanche, je suis plutôt d’accord avec ce que tu as écrit : ça donne vraiment l’impression d’un retour en arrière par rapport à Interface Builder. Je n’arrive toujours pas à m’y faire.
J’aurais nettement préféré qu’Apple travaille à améliorer le système des bindings dans Cocoa, ainsi qu’à retoucher certaines classes d’AppKit pour qu’on ait besoin de moins de code pour les faire tourner. Mais je me demande s’il y a encore quelqu’un dans l’équipe actuellement en charge de MacOS qui est au courant de l’existence de ce système de bindings…
@marc_os
"Font chier ces devs venant du web qui ont visiblement pris le pouvoir chez Apple."
C’est le reflet d’une réalité factuelle : le web a gagné la "guerre" des plateformes applicatives.
@ fte : « C’est le reflet d’une réalité factuelle : le web a gagné la "guerre" des plateformes applicatives. »
Hélas.
Comme ça a déjà été le cas pour la guerre des OS, la médiocrité a gagné.
@BeePotato
"Comme ça a déjà été le cas pour la guerre des OS, la médiocrité a gagné."
Médiocrité ? Selon quels critères ?
Le web est universel, sans compétition.
Le web propose le moteur d’affichage d’interface / de document le plus avancé, sans compétition. (Les moteurs type Unreal sont dans une autre catégorie.)
Le web est la plateforme la plus largement documentée.
Le web est développé par la plus large communauté de développeurs, sans compétition.
Le web n’est pas propriétaire, même s’il existe évidemment des luttes d’influence des poids lourds du web.
…
Donc quels sont tes critères pour la déclarer médiocre ?
Selon les miens, elle est loin d’être parfaite, certes, mais elle est damn fucking good.
@ fte : « Médiocrité ? Selon quels critères ? »
Celui de la qualité (jugée elle-même principalement sous l’angle de l’ergonomie et des performances) des applications.
Ce qui n’est pas surprenant pour des applications construites sur des bases qui n’ont pas été prévues pour ça, reposant sur un modèle (la navigation de page en page) qui n’est pas du tout fait pour ça. Ce dernier point se retrouve certes masqué dans le cas des applications web distribuées empaquetées comme applications de bureau, mais en échange d’une lourdeur supplémentaire.
« Le web est universel, sans compétition. »
Presque universel — jusqu’à ce qu’on se lance justement dans les développements de ce genre, qui rappellent vite l’hétérogénéité des moteurs de rendu.
Sauf bien sûr si on considère, comme c’est hélas de plus en plus souvent le cas, que web == Chrome.
« Le web propose le moteur d’affichage d’interface / de document le plus avancé, sans compétition. »
🤣 🤣 🤣
Non.
« Le web est la plateforme la plus largement documentée. »
En effet. Je n’ai pas dit qu’il n’avait que des mauvais côtés.
« Le web est développé par la plus large communauté de développeurs, sans compétition. »
En effet aussi.
Mais ça n’est en rien un gage de qualité — au contraire, quand on attire le plus grand nombre de développeurs, on attire aussi inévitablement le plus grand nombre de mauvais développeurs.
« Le web n’est pas propriétaire »
En effet.
Ce qui n’est pas non plus un gage de qualité.
« Selon les miens, elle est loin d’être parfaite, certes, mais elle est damn fucking good. »
Sans doute, mais vu que tu arrives à te satisfaire de Windows, je sais bien que nous n’avons pas les mêmes critères. 😉
@BeePotato
"Celui de la qualité (jugée elle-même principalement sous l’angle de l’ergonomie et des performances) des applications."
Ce n’est pas un critère de plateforme, c’est un critère d’application. Il y a des applications dégeulasses sur la "meilleure" plateforme et des applications superbes sur le "médiocre" web. Ça dépend de si l’éditeur se sort les pouces du cul ou pas, et fort peu de la plateforme.
Fort peu. Pas pas du tout.
Quant à Windows, je note la pique, je la goûte, mais tu sais parfaitement qu’elle est qu’une pique. Windows a des qualités que macOS n’a pas et inversement. Et surtout, je ne travaille ni avec Windows ni avec macOS. Je travaille avec des applications qui par hasard tournent sur des OS et sur certaines machines.
@ fte : « Ce n’est pas un critère de plateforme, c’est un critère d’application. »
Non non, je parle bien de ce que permet (facilement, sans avoir à tout réécrire soi-même) la plateforme.
« Ça dépend de si l’éditeur se sort les pouces du cul ou pas, et fort peu de la plateforme. »
Ça dépend beaucoup de la plateforme, et évidemment, par dessus ça, du sérieux du développeur.
Bien sûr, si on considère que l’effort fait par le développeur intègre le choix de la plateforme, alors ça dépend complètement du développeur.
Mais tout de même aussi de la plateforme. 🙂
« Quant à Windows, je note la pique, je la goûte, mais tu sais parfaitement qu’elle est qu’une pique. »
Ah non, du tout : c’est bien une réalité. Windows certes devenu beaucoup moins médiocre avec le temps, mais reste pitoyable sur bien des points et son histoire reste un des meilleurs exemples de victoire de la médiocrité.
« Windows a des qualités que macOS n’a pas et inversement. »
Oui, évidemment, et si ce qu’on doit faire dépend absolument de ces qualités, ça guide le choix de plateforme. Mais cette jolie (et si classique) pirouette politiquement correcte ne dit rien sur le nombre ou l’importance de ces qualités exclusives à l’un ou à l’autre et n’apporte donc rien à une discussion sur ce sujet.
« Et surtout, je ne travaille ni avec Windows ni avec macOS. Je travaille avec des applications qui par hasard tournent sur des OS et sur certaines machines. »
Ça explique bien des choses. 😁
Pour ma part, j’utilise bien l’OS sur lequel tourne mes applications, profitant autant que possible des fonctions que cet OS fournit aux applications ainsi que directement à l’utilisateur que je suis.
@BeePotato
"🤣 🤣 🤣
Non."
Tellement si. 🤷♂️
@ fte : « Tellement si. 🤷♂️ »
Ben non, pourtant.
@BeePotato
"Ben non, pourtant."
Carrément même, vachement oui.
Charge CPU entre 0,6 et 1,4 soit 1,,0 en moyenne à priori sur un MBP avec 2,6 GHz 6-Core Intel Core i7
(Je ne suis pas sûr que la comparaison Intel - M1 dans l'article soit pertinente. Il faudrait un panel de machines bien plus large.)
HS: très bons goûts musicaux Pierre 🤩
Hé hé, @Pierre Dandumont , t’en as donc estampillés « Hoover » alors? 🤓
Leurs premières années étaient leurs meilleures, les plus originales. Maintenant c’est (pour moi) de la soupe pop reconnaissable en quelques secondes. 😔
Est-ce qu'on peut le désactiver ? (Pour ma part je ne m'en sert jamais).