Un ingénieur Microsoft explique comment un code de mauvaise qualité peut ralentir un PC Windows

Un ingénieur Microsoft explique comment un code de mauvaise qualité peut ralentir un PC Windows

Suppression progressive du support de Windows 10 : surmonter les problèmes potentiels

Alors que la période de support de Windows 10 touche à sa fin, Microsoft a récemment lancé un rappel crucial aux utilisateurs. L’entreprise a également dévoilé la liste des PC Surface qui ne peuvent pas être mis à niveau vers Windows 11 en raison d’une configuration système non satisfaite. Leur recommandation est claire : pensez à investir dans un nouvel appareil, de préférence un PC Copilot+, pour garantir des performances optimales.

Réactions des utilisateurs aux changements du système d’exploitation

Face à cette transition imminente, de nombreux particuliers discutent de leurs stratégies futures. Les utilisateurs de systèmes antérieurs à 2015, incompatibles avec Windows 11, envisagent un retour à Windows 8 ou 8.1. Ce choix s’explique en grande partie par la perception que l’ancien système d’exploitation offre une meilleure réactivité que Windows 10. Il est toutefois important de noter que Windows 8.1 a atteint la fin de son cycle de support en janvier 2023, ce qui en fait un choix moins sûr malgré sa rapidité perçue.

Causes sous-jacentes de la lenteur du système

De nombreux utilisateurs constatent des performances médiocres sur leurs appareils, souvent imputables à un matériel obsolète. Un éditorial pertinent de David Uzondu, intitulé « Un logiciel négligé : pourquoi pensez-vous avoir besoin d’un nouveau matériel », souligne l’importance de l’optimisation logicielle. Un article de blog récent de Matt Hamrick, ingénieur senior en escalade chez Microsoft, s’inscrit dans cette optique, en soulignant l’impact considérable des problèmes de gestion de la mémoire sur les performances système.

Gestion de la mémoire et performances des applications

Dans son blog, Hamrick aborde l’impact des fuites de mémoire et des situations de saturation de mémoire (OOM) causées par une mauvaise optimisation logicielle.À l’aide d’une application. NET 7 mise à jour, il illustre comment un reloadOnChangeparamètre mal configuré peut entraîner de graves problèmes de performances. Si ce paramètre est défini sur « true » au lieu de « false », cet oubli peut entraîner des fuites de mémoire, entraînant une dégradation des performances du système, voire des plantages de l’application.

Comprendre le reloadOnChangeparamètre

Ce reloadOnChangeparamètre indique au système de surveiller des fichiers spécifiques afin de détecter toute modification des paramètres. Cette fonctionnalité permet le rechargement dynamique, permettant aux applications d’accéder immédiatement aux valeurs modifiées sans nécessiter de redémarrage. Malheureusement, une mauvaise utilisation de cette fonctionnalité peut entraîner un épuisement progressif de la mémoire, ce qui nuit à l’efficacité du système.

Avis d’experts sur l’optimisation du code

Hamrick souligne l’importance de bonnes pratiques de codage, en expliquant :

L’impact de ce code sera d’autant plus important qu’il sera exécuté fréquemment. Le problème n’est pas apparent, mais voici le déclencheur : reloadOnChange: true.

….

reloadOnChange: trueest vraiment destiné à être utilisé uniquement lors du démarrage de l’application si un fichier de configuration personnalisé est consommé qu’ASP. NET lui-même ne consomme pas déjà automatiquement (en supposant que ces valeurs par défaut n’ont pas été modifiées).

Au lieu de cela, comme mentionné ci-dessus, certaines personnes ont utilisé par erreur ce code dans quelque chose comme une action de contrôleur ou un composant middleware pour accéder à une valeur de configuration nécessaire, sans savoir ce qu’il fait sous le capot (sans savoir non plus que la configuration qu’ils recherchaient généralement était déjà chargée (et surveillée) dans le système de configuration de l’application).

Outils de diagnostic des problèmes de mémoire

Grâce à divers outils de débogage, dont WinDbg, Hamrick a réussi à identifier les failles du code problématique. Pour les personnes intéressées, l’article complet est disponible ici, sur le site de la communauté technique de Microsoft.

Il est à noter que, bien que l’analyse de Hamrick se concentre sur une application développée avec. NET 7, les problèmes abordés ne se limitent pas à cette version. Ils peuvent également affecter les applications créées avec les versions prises en charge du framework. NET.

Source et images

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *