Depuis maintenant quelques semaines, j’ai repris les contributions au projet Calligra, et plus particulièrement au traitement de texte (cf ce journal pour plus d’informations). Du coup, quand sur la liste de courriel des développeurs un comparatif a été envoyé, comparant LibreOffice et Calligra sur le temps de chargement d’un document volumineux (800+ pages, table des matières de 60+ pages), et révélant un sévère désavantage pour Calligra, mon sang ne fit qu’un tour : un facteur 4 dans le temps de chargement n’est pas acceptable, même s’il s’explique par l’absence de travail d’optimisation sur ce point…
Partons donc à la recherche de ces lenteurs, et profitons-en pour parler des méthodes d’analyse des performances d’un programme sous Linux !
Sommaire
- 1) dans des temps anciens, callgrind…
- 2) Performance Counters for Linux, perf, la révolution…
- 3) hotspot, rendons ça plus visuel…
1) dans des temps anciens, callgrind…
Valgrind est un outil bien connu des développeurs C/C++ notamment. Il est connu comme étant un excellent outil pour détecter et analyser les problèmes mémoire, qu’il s’agisse de fuites ou d’utilisation de pointeurs libérés… Mais c’est une vraie collection d’outils, avec également celui qui fut un grand allié dans la recherche des problèmes de performance, callgrind.
Callgrind fonctionne en remplaçant le programme de chargement du binaire par le sien, et en faisant une analyse dynamique du code au fur et à mesure de son exécution. Cette analyse est complète (il ne s’agit pas d’instantanés à une fréquence donnée) mais a un coût colossal : un programme dans callgrind peut facilement être dix fois plus lent qu’en dehors de callgrind. Sur un programme complexe, on procède souvent à une analyse réduite avec un déclenchement retardé de callgrind, puis en l’interrompant quand l’événement que l’on souhaite analyser est passé. L’illustration en est donnée sur cet article d’analyse de plasma avec callgrind.
Heureusement, ce temps est désormais révolu et d’autres outils sont disponibles maintenant, bien plus flexibles. Celui que je vais utiliser est désormais un indispensable dans ma boite à outil, qu’il s’agisse d’administration système, de travail de DBA ou de développement : perf.
2) Performance Counters for Linux, perf, la révolution…
Bon la révolution ne date pas d’hier (2009 dans le noyau, 2010 dans RHEL, 2011 dans Debian Squeeze…), mais finalement on en a peu parlé sur DLFP, et ce n’est donc pas si connu que ça… Ou l’inverse, je ne sais plus…
perf utilise les compteurs matériel, des points de traçage dans le noyau ou dans les applications afin de collecter des événements. Qu’est-ce qu’un événement, me direz-vous ? Je suis heureux que vous me posiez cette question : la commande perf list en liste plus de 300 chez moi… Ils se répartissent en deux catégories selon l’origine, logicielle ou matérielle. Par exemple chaque changement de tâche par l’ordonnanceur du noyau va être un événement logiciel. Les événements matériels correspondent quant à eux aux données de la PMU (Performance Monitoring Unit), une partie du processeur qui va surveiller des événements au niveau micro-architectural comme le nombre de cycles écoulés, les succès/échecs sur le cache…
Bien évidemment, on ne peut pas enregistrer chaque occurrence de ces événements : à chaque seconde, des milliards de cycles s’écoulent, et traiter ces événements déclencherait à nouveau un nombre conséquent d’événements… Le processeur maintient donc des compteurs d’événements, que le noyau va consulter.
perf est donc la face visible de tout ce travail, et permet donc pendant une période et à une fréquence donnée d’enregistrer et visualiser le nombre d’occurrences de ces événements.
2.a) Petit exemple
Prenons un cas simple, echo 'bonjour monde' :
% perf stat /bin/echo 'bonjour monde'
bonjour monde
Performance counter stats for '/bin/echo bonjour monde':
0.42 msec task-clock:u # 0.556 CPUs utilized
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
62 page-faults:u # 0.146 M/sec
205,471 cycles:u # 0.485 GHz
14,061 stalled-cycles-frontend:u # 6.84% frontend cycles idle
45,629 stalled-cycles-backend:u # 22.21% backend cycles idle
219,967 instructions:u # 1.07 insn per cycle
# 0.21 stalled cycles per insn
49,000 branches:u # 115.556 M/sec
<not counted> branch-misses:u (0.00%)
0.000763131 seconds time elapsed
0.000819000 seconds user
0.000000000 seconds sys
L’exécution de cette commande simple a duré 0,76ms, 205 000 cycles processeurs, 220 000 instructions, avec une consommation de 0,42ms de CPU.
Pour comparaison, avec sleep 1 :
% perf stat sleep 1
Performance counter stats for 'sleep 1':
0.45 msec task-clock:u # 0.000 CPUs utilized
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
62 page-faults:u # 0.137 M/sec
249,795 cycles:u # 0.554 GHz
21,583 stalled-cycles-frontend:u # 8.64% frontend cycles idle
60,183 stalled-cycles-backend:u # 24.09% backend cycles idle
221,601 instructions:u # 0.89 insn per cycle
# 0.27 stalled cycles per insn
49,186 branches:u # 109.046 M/sec
<not counted> branch-misses:u (0.00%)
1.001224745 seconds time elapsed
0.000899000 seconds user
0.000000000 seconds sys
On note que le task-clock reste très faible puisqu’il s’agit du temps processeur consommé, et sleep ne fait pas une attente active où il consommerait inutilement du processeur.
2.b) perf top pour voir ce que fait notre système
perf top permet d’avoir une vue instantanée de tout le système, noyau inclus. Lors de cette capture, un btrfs scrub est en cours sur deux disques en LUKS.
Vous notez en haut de l’interface que l’événement capturé est 'cycles' (le nombre de cycles processeur consommés), à une fréquence de 4 kHz (4 000 captures par seconde, pour les moins scientifiques d’entre nous). Cela montre le fonctionnement de perf qui réalise un échantillonnage du système.
Dans cette interface, on peut également aller dans chaque fonction et annoter les fonctions pour voir exactement où le CPU est consommé. Quand on ne dispose pas des symboles de debug (mon principal reproche contre Archlinux), le code assembleur sera affiché.
Cette commande est utilisable également sur un serveur en production, et peut donc aider dans des cas sensibles d’analyse de performances : elle n’a pas d’impact sur le système quand il tourne, et permet de creuser très facilement sur les fonctions les plus gourmandes en CPU, qu’il s’agisse de fonctions dans l’espace utilisateur ou dans l’espace noyau. Grâce à cet outil, un collègue et moi-même avons su identifier (puis corriger avec les outils présentés ensuite) un problème de performance sur PostgreSQL où la réplication logique provoquait une forte consommation de CPU en système.
2.c) perf record pour analyser un programme
La commande perf record est, dans le cas qui nous intéresse ici, la plus utile. Elle permet, pour un ensemble de processus donnés (ou l’ensemble du système) d’enregistrer un fichier perf.data qui va contenir un ensemble d’événements. Nous pourrons ensuite utiliser des outils comme perf report pour disposer de la même interface que perf top, mais sur un état figé. Quand on dispose d’un élément reproductible (ici, ouvrir et afficher le fichier OpenDocument-v1.2-part1.odt), on peut facilement modifier l’application pour comparer l’évolution.
Un paramètre assez important à perf record est --call-graph qui permet d’enregistrer les piles d’appel à chaque événement. Ainsi, au lieu de voir que l’on a passé 50 % du temps dans une fonction foo(), on peut découvrir qu’en fait on a passé 45 % du temps dans un appel de foo() par bar(), et 5% du temps dans des appels divers à foo(). Plusieurs valeurs peuvent être passées à --call-graph, pour spécifier la méthode de capture des piles d’appel, avec un choix entre fp (utilisation du 'frame pointer' qui doit être mis par le compilateur), dwarf (utilisation des données de debug du programme) et lbr (utilisation des registres LBR, disponibles uniquement sur les processeurs Intel récents). Dans mon cas, j’utilise dwarf qui m’a donné les meilleurs résultats. Un autre paramètre optionnel est -F pour spécifier la fréquence d’échantillonnage. Sur des périodes de captures courtes, ce paramètre peut être utile pour obtenir des traces plus utilisables.
Lançons ça sur Calligra Words :
% perf record --call-graph dwarf ./words/app/calligrawords ../OpenDocument-v1.2-part1.odt
[… sortie diverse de debug de différents composants de calligra …]
[ perf record: Woken up 2749 times to write data ]
Warning:
Processed 93565 events and lost 21 chunks!
Check IO/CPU overload!
[ perf record: Captured and wrote 691.125 MB perf.data (85798 samples) ]
691 MB, c’est costaud. D’ailleurs, un certain nombre d’événements n’ont pas pu être capturés. Ajouter les paramètres --aio -z règlent ce souci en compressant la sortie et en faisant des IOs asynchrones.
Avec perf report, on peut explorer l’enregistrement, ce qui donne une interface (et des fonctionnalités) proches de perf top :
Néanmoins, sur un programme aussi complexe qu’un traitement de texte, cet affichage n’est pas le plus adapté… Heureusement…
3) hotspot, rendons ça plus visuel…
KDAB est une société de service en logiciels, spécialisée sur Qt, qui contribue au libre : plusieurs de ses salariés sont d’éminents développeurs KDE, elle a envoyé de nombreux patchs sur Qt, ouvert différents outils autour de Qt…
Et l’un de ses derniers nés est hotspot, je cite, « L’interface à Linux perf pour l’analyse de performance », disponible en licence GPL ou commerciale.
L’outil est extrêmement simple à prendre en main : on ouvre dans l’interface le fichier perf.data, et après quelques secondes, l’interface (très complète) apparaît.
La visualisation la plus intéressante est le 'Flame Graph'. Grâce à lui, on peut en quelques instants voir où le temps s’est écoulé, et donc en déduire les endroits à optimiser.
On trouve donc facilement le point chaud, il n'y a « plus qu’à » le corriger… Bon, « le plus qu’à » a pris plusieurs jours, plusieurs patchs, des versions incorrectes, différents atermoiements… Les plus curieux peuvent aller regarder sur cette 'merge-request' pour les correctifs de cette fonction, sachant que d’autres correctifs ont été intégrés entre-temps pour d’autres points 'tièdes' repérés avec hotspot également.
Une fois ce point chaud corrigé, un second point chaud était assez apparent : l’ajout de texte dans un QTextDocument. L’analyse a permis de révéler un algorithme en O(n) lors de l’ajout de textes sur QTextDocument en fonction du nombre de curseurs qu’on maintient sur le document. Or, dans Calligra, chaque annotation et chaque marque-page dans le document est représenté avec un curseur, et il y en a plusieurs milliers. Là aussi, les plus curieux peuvent aller voir le bug Qt correspondant que j’espère corriger dans les prochains mois… Hé oui, contribuer à un logiciel peut parfois amener à en corriger beaucoup plus…
Pour information, une fois les problèmes corrigés, je suis arrivé à ce niveau de performances :
On voit que le temps requis pour ouvrir le fichier est passé de 20 secondes à 8 secondes, et hotspot va continuer de m’aider à trouver les endroits restant à optimiser.
Attention tout de même : le principal inconvénient d’un tel outil est sa simplicité d’utilisation. C’est assez « enivrant » et l’on se prend vite au jeu de gratter des cycles CPU à droite et à gauche, quitte à délaisser le développement de fonctionnalités ou la correction de bugs…
J’espère en tout cas que cet article vous permettra de trouver d’autres optimisations à faire sur les programmes que vous développez ou utilisez.
Aller plus loin
- Calligra (166 clics)
- Hotspot (Github) (138 clics)
- Linux perf (57 clics)
# Flame Graphs
Posté par paulez (site web personnel) . Évalué à 9.
Les Flame Graphs sont vraiment super puissants, il y a pas mal d’exemples ici: http://www.brendangregg.com/flamegraphs.html
Je ne connaissais pas Hotspot, merci pour la découverte. Super article !
# Je reste sur ma faim !
Posté par Dring . Évalué à 10.
Super article, merci Pinaraf ! Par contre, j'espérais une description un peu plus détaillée des lenteurs repérées et des corrections apportées .; là à part le problème sur QTextDocument, c'est le désert. Mais bon, tu m'as motivé, je vais aller jeter un oeil à la merge request.
[^] # Re: Je reste sur ma faim !
Posté par Pinaraf . Évalué à 10.
Toutes mes excuses pour ce 'trou', je craignais que cela ne brouille le message qui vise à montrer perf/hotspot avant tout.
La lenteur majeure identifiée dans Calligra, visible sur la capture d'écran d'hotspot, est la fonction
KoTextRangeManager::textRangesChangingWithin. La classeKoTextRangeManagerstocke tous les objetsKoTextRange, qui servent à représenter notamment les marque-pages, les annotations… Cela correspond donc à un point de départ et un point d'arrivée dans un document. Jusqu'à maintenant, ces éléments étaient stockés non triés. J'ai changé ça pour stocker dans une structure ordonnée afin de pouvoir faire des recherches enO(log(n))au lieu deO(n)(le problème est similaire au bug surQTextDocument). La structure est complexe parce que lesKoTextRangepeuvent correspondre à un point fixe ou à une sélection, et ils peuvent se superposer. J'en ai aussi profité pour stocker par classe deKoTextRange, vu que le code derrière filtrait…Dans le code de mise en page, la fonction de recherche est appelée à chaque paragraphe. Dans la sauvegarde, elle est appelée encore plus souvent (pour d'autres raisons). Le gain a donc été phénoménal.
# Super article
Posté par Ririsoft . Évalué à 9.
Il est top ton article, merci beaucoup !
J'en étais resté à callgrind ou aux outils intégrés dans Go. Tu m'as ouvert les yeux sur un nouvel univers passionnant !
[^] # Re: Super article
Posté par woffer 🐧 . Évalué à 3.
Pour Go, je ne suis pas sûr que perf soit le plus adapté (un peu comme gdb ne permet pas d'avoir un debug optimal pour le Go. Il faut mieux utiliser delve).
# Compilation de perf sous Gentoo
Posté par Denis Bernard (site web personnel) . Évalué à 6.
Sous Gentoo, "perf" est en "tilde" (masqué) et il y a de très nombreuses options. Ne pas oublier d'activer "slang" sinon on a une interface très réduite et il ne semble pas possible d'avoir l'équivalent de la seconde illustration.
Pour info, les options possibles : "audit crypt demangle doc gtk java libpfm lzma perl python slang systemtap unwind zlib debug numa".
La documentation de perf (dans "/usr/share/doc/perf-x.xx") est copieuse !
# Un (petit) peu HS : SQLite ?
Posté par Papey . Évalué à 10.
Merci beaucoup pour cet article !
Un peu hors sujet mais j'ai toujours été intrigué par cet article du site SQLite, qui semble proposer de bonnes amélioration de perfs sur les documents Open Document en les encapsulant dans une base SQLite plutôt que dans un zip.
Je profite donc d'avoir sous la main en la personne de Pinaraf un développeur compétent en formats office pour essayer d'en savoir plus sur le fait que cette solution n'ait pas été choisie. Est-ce parce qu'elle n'a pas été étudiée ? Parce que ce serait trop compliqué de tout changer ? Parce qu'elle n'est pas appropriée (et pourquoi) ?
Merci pour ces éclaircissements :-)
[^] # Re: Un (petit) peu HS : SQLite ?
Posté par Pinaraf . Évalué à 10.
Je connais cet article, qui est très intéressant effectivement, mais reste (et restera sûrement) entièrement théorique. Il m'est difficile de répondre sur l'étude (ou l'absence d'étude) concernant sa réalisation. Par contre les deux autres questions sont plus faciles.
En mars 2021, j'ai encore reçu un document rédigé avec le format Microsoft Word historique, introduit avec Word 97. En même temps que Clippy, en 1996. 25 ans d'inertie… Donc oui c'est très très très … très très compliqué de tout changer.
Les suites bureautiques ont heureusement toutes un système de filtre pour importer des documents d'autres logiciels, mais encore aujourd'hui la lingua franca des documents éditables reste dans beaucoup d'esprits le format Microsoft Office 97-2003.
Les deux prétendants légitimes au trône sont les formats Microsoft Office Open XML et Open Document. Ce qui me transitionne pour ta deuxième question…
Tout d'abord, par rapport à l'article, il eut été intéressant que la comparaison ait également lieu avec le format OOXML et pas seulement ODT. L'OOXML répond notamment à la problématique mise en avant ici (comment modifier la diapo 42 sans tout réécrire) avec un découpage en fichiers distincts de chaque diapositive. (ce qui peut compliquer d'autres éléments dans l'implémentation, mais passons)
L'OOXML et l'ODT ont de nombreux points commun. Ils sont normalisés, sous la forme d'une archive zip embarquant des fichiers XML.
Pourquoi zip ? Parce qu'il est ouvert, libre de brevets, dans le domaine public depuis 1989, avec de multiples implémentations, et même normalisé ISO depuis 2015 (en conséquence de son usage dans l'ODT, l'OOXML et l'epub d'ailleurs). SQLite, a contrario, serait là dessus un mauvais choix : il n'existe à ma connaissance qu'une seule implémentation du format de fichier, et le format a largement évolué en 2004 avec l'introduction de SQLite3, avec une rupture de compatibilité.
Et en aparté, pourquoi XML ? Outre le fait que dans les années 2000 c'était le Format à la mode, avec un F majuscule, un point qu'on néglige énormément en ces temps de JSON, YAML et autres TOML, le XML a intégré de base une technologie fantastique : les namespaces. Cela permet d'avoir des dépendances à d'autres normes et donc d'éviter d'avoir à réinventer la roue.
L'en-tête du fichier content.xml d'un fichier ODT généré par LibreOffice Writer contient une quinzaine de namespaces. Plusieurs sont assez intéressants puisqu'ils aboutissent à une réduction de la taille de la norme OpenDocument : les formules mathématiques sont par exemple représentées en MathML, les modèles XForms peuvent être directement intégrés, on utilise RDF… Le point «And so forth» de l'article de SQLite est vite incompatible avec cette approche (découpage du contenu en tables, avec des relations entre les tables et cie), à moins de définir un schéma SQL extrêmement strict et précis, qui à lui seul représentera des milliers de lignes de SQL, et qui remplacerait du coup des morceaux de la norme ODT…
Si l'on s'arrête strictement au concept s/zip/SQLite/, le point qui moi me crispe d'emblée, c'est l'absence d'implémentation alternative du format SQLite 3 (j'ai bien trouvé en grattant 2/3 projets décédés…). Sans ça, on n'a pas de preuve de la qualité de la description du format de fichier.
Pour finir cette bien longue réponse, je pourrais également ajouter ces éléments de la norme OpenDocument :
- un fichier OpenDocument peut être représenté en un fichier XML unique, sans le .zip autour (§3.1.1 de la v1.2-part1)
- le «package» est défini dans la partie 3 de la norme, la partie la plus courte. Rien n'interdit de proposer à l'OASIS une évolution sur du SQLite3…
[^] # Re: Un (petit) peu HS : SQLite ?
Posté par Papey . Évalué à 7.
Merci d'avoir pris le temps de répondre de manière aussi détaillée.
Il est vrai que les perspectives d'amélioration des temps d'ouverture et d'enregistrement des documents Libre Office font quand même bien envie.
Concernant la pérennité du format, l'équipe SQLite s'engage à rester rétro-compatible avec le format SQLite3 jusqu'en 2050 a minima, ce qui semble tout à fait important à l'heure de "l'agilité" parfois mal comprise et pouvant confiner à l'agitation marketing (marketing dont SQLite n'est pas exempte, mais a minima plus dans le fait de changer le format de fichier). Mais effectivement zip a eu 10 ans d'avance et une plus grande stabilité dans les faits, et c'était encore plus vrai au moment de la création des standards en question.
Pour ce qui est de l'inexistence d'implémentations tierces, c'est bien sûr vrai (modulo les 2 ou 3 que tu mentionnes) mais c'est peut-être lié au fait que la bibliothèque officielle soit dans le domaine public et écrite en C ANSI et très compacte donc facilement adaptable à tout système sans avoir à réinventer la roue.
Pour ce qui est du "découpage du contenu en tables, avec des relations entre les tables et cie", ce n'est pas ce que j'ai compris de la fin de l'article, qui au contraire souligne le fait qu'on peut tout à fait stocker du XML (avec les namespaces donc) dans des tables SQL, en gagnant en plus la possibilité de les versioner et indexer plus facilement. Je reprends juste ce passage :
"Some readers might be reluctant to consider SQLite as an application file format because they have been inculcated with the idea that all SQL database schemas must be factored into third normal form and store only small primitive data types such as strings and integers. Certainly relational theory is important and designers should strive to understand it. But, as demonstrated above, it is often quite acceptable to store complex information as XML or JSON in text fields of a database."
Mais les autres points sont aussi abordés.
Après je te suis sur l'inertie importante en terme d'habitude de formats de fichiers, mais si on divise par 10 le temps d'ouverture et d'enregistrement ça pourrait booster l'adoption (la passer de 20 ans à 10 ans ?).
Il ne reste plus qu'à (re?)lancer le sujet auprès de l'OASIS, comme tu le suggères :-)
[^] # Re: Un (petit) peu HS : SQLite ?
Posté par Pinaraf . Évalué à 10.
J'aurais du répondre à ce point tiens…
Où est la démonstration que cet aspect est bien le goulot d'étranglement ?
Dans mon cas, lecture de la norme OpenDocument, la compression Zip est invisible dans hotspot. Évidemment, elle est présente et a un coût, mais ce coût est tellement faible qu'avec la fréquence d'échantillonnage par défaut je n'ai pas su le voir. En augmentant à 8kHz, je commence à l'apercevoir, avec une consommation de moins de 0,01% du CPU…
J'ai du mal à analyser LibreOffice (je n'ai pas les symboles de debug, défaut d'archlinux, et je ne peux pas recompiler LibreOffice, défaut de courage :) ), mais je doute que les chiffres soient si différents de ce que je vois sur un perf rec sur lowriter sur la norme OpenDocument.
Cet article reste très intéressant, mais le prédicat de base (le Zip est un goulot d'étranglement) illustre bien l'intérêt de perf et de l'analyse par rapport au doigt mouillé pour améliorer les performances : ce qui coûte dans l'ouverture d'un fichier OpenDocument, en tout cas dans le cas d'un fichier complexe, ce n'est pas le format Zip.
Dans le cas de la sauvegarde, il faudrait que je creuse sur Calligra, mais dans le cas de LibreOffice cela ne me semble pas non plus être le cas (à nouveau, symboles de debug tout ça)
[^] # Re: Un (petit) peu HS : SQLite ?
Posté par Papey . Évalué à 4.
Bien vu en effet pour le profilage ! Pour l'écriture, l'argument de l'équipe SQLite est que l'on peut préparer l'écriture du fichier en continu, en utilisant la gestion fine des versions sur des bouts de document, permise par la base SQL. Il ne reste plus qu'à mettre à jour les pointeurs de versions quand l'utilisateur clique sur "enregistrer", pour que la version en cours devienne la version officielle, ce qui est quasi instantané.
# Taille des données
Posté par T_T_T . Évalué à 6.
Tu mentionnes la taille de données (691 Mo dans ton cas).
L'utilisation de
perfme donne également des données monstrueuses.Et les possibilités de filtres des événements ne sont finalement pas si fines (à moins d'avoir raté quelque chose).
Je ne crois pas qu'on puisse se concentrer sur un module, ou alors ignorer les appels hors du programme qu'on cherche à inspecter (l'intérêt de regarder dans telle ou telle bibliothèque sur laquelle on n'a pas la main est souvent limité).
Est-ce que je rate quelque chose? Est-ce que quelqu'un a un "truc"?
[^] # Re: Taille des données
Posté par Pinaraf . Évalué à 10.
Les paramètres
--aio -zchangent ça radicalement. On passe de 700MB à un petit 30MB de mémoire…[^] # Re: Taille des données
Posté par T_T_T . Évalué à 4.
Ah bien sûr ! J'avais lu la phrase dans la dépêche (merci d'ailleurs) mais j'avais associé les deux options à la résolution d'événements non capturés, pas à la compression des données.
Mais l'option
-zaurait dû de mettre la puce à l'oreille, quand même!# Programmes à optimiser ?
Posté par mlinux . Évalué à 9. Dernière modification le 15 avril 2021 à 09:08.
Hello ;=)
Alors là je dis Bravo ! Mettre les mains dans le cambouis pour que tout le monde en profite ça fait plaisir, merci aussi :=)
Quelle serait votre liste de programmes urgents à optimiser ?
[^] # Re: Programmes à optimiser ?
Posté par Pinaraf . Évalué à 7.
L'ensemble des programmes qui tournent sur ma machine ? :)
Plus sérieusement, s'il y avait une urgence sur ma machine, je m'en occuperais. Mais j'aimerais beaucoup que du temps soit consacré à l'optimisation de l'ensemble des programmes qui constituent le bureau Linux, Plasma dans mon cas. J'ai beau avoir une machine puissante, j'aimerais que ma machine démarre plus vite.
Après mon principal reproche aujourd'hui c'est surtout la conso mémoire qui est partie en flèche, en particulier sur les navigateurs web. Firefox consomme moins que Chromium, heureusement, mais ça reste beaucoup trop pour l'usage que j'en ai.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10. Dernière modification le 15 avril 2021 à 10:19.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Entrée de suivi
Posté par Atem18 (site web personnel) . Évalué à 9.
Tu serais surpris du nombre de personnes y ayant encore recours.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Entrée de suivi
Posté par nekopep . Évalué à 10.
En fait celui ci est un flame chart , c'est un peu différent car sur l'axe X nous avons le temps. C'est adapté aux navigateur web car l'interpréteur javascript est mono-thread.
Vidéo présentation flamegraph @ 26:59 qui explique la différence.
Vidéo très intéressante par ailleurs pour comprendre l'interprétation ds flamegraph.
# Quelques infos supplémentaire
Posté par reno . Évalué à 8.
Bon j'avoue ne pas vraiment comprendre l'analyse des performances sous Linux, il y a perf, SystemTap, bpftrace, ça fait beaucoup..
Mais pour ceux qui comprennent mieux, LWN vient de faire un article sur le sujet: Comparing SystemTap and bpftrace: je me permets d'envoyer un subscriber link (à ne pas diffuser inconsidérément merci):
https://lwn.net/SubscriberLink/852112/8a228aa8184dabc9/
[^] # Re: Quelques infos supplémentaire
Posté par Pinaraf . Évalué à 10.
systemtapetbpftracesont concurrents. Mais ils sont beaucoup plus complets que de la simple analyse de performance. Ils se branchent sur des événements et les interceptent, peuvent inspecter les différents paramètres dans le cas d'appels de fonctions… On peut par exemple regarder l'ensemble des fichiers modifiés en temps réel sur un système , l'ensemble des connexions réseau… des tas d'outils dans le style de top, iftop ou ss peuvent être réimplémentés ainsi.Ce qui est fait ici serait peut-être faisable avec
systemtapetbpftrace, mais ça revient à réimplémenterperfavec ces derniers. C'est du boulot.# Narration
Posté par grolandais . Évalué à 10.
Bonjour,
Le sujet du billet m'est totalement étranger et j'avoue que je n'ai pas tout pipé mais j'ai un eu grand plaisir à tout lire jusqu'à la fin tant c'était bien raconté. Il me paraissait alors important de féliciter les contributeurs pour cette qualité rédactionnelle, ce que je fais par le truchement de ce commentaire.
Merci et bravo !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.