Quand votre logiciel se fige : améliorer les performances de façon systématique

Qualité et sécurité

Le logiciel s'est développé au fil des années, chaque version a apporté de nouvelles fonctions. Un jour, avec de gros fichiers, les utilisateurs attendent une réaction pendant plusieurs minutes, et la fenêtre affiche « Ne répond pas ». Des optimisations ponctuelles faites au feeling aident alors rarement. Il faut une démarche systématique.

D'abord mesurer, ensuite modifier

La cause la plus fréquente d'une optimisation vaine, c'est de deviner. Mesurez d'abord, et ce avec des données réalistes : les grandes constructions, séries de mesures ou projets pour lesquels vos utilisateurs attendent réellement. Un profileur, par exemple le profileur de performances de Visual Studio, montre où le temps passe vraiment. Consignez une mesure de référence pour trois à cinq déroulements typiques. C'est la seule façon de prouver plus tard ce qu'une mesure a apporté.

Recenser et classer les pistes d'amélioration

Dans un logiciel qui a grandi au fil du temps, il y a rarement un seul frein. Le plus souvent, ce sont de nombreux points qui s'additionnent. Recensez-les dans un document de concept et évaluez chacun selon son effet et son coût. Les candidats typiques sont :

Mettez d'abord en œuvre les points les plus efficaces et mesurez à nouveau après chaque étape.

Calculer en arrière-plan

Tous les calculs ne peuvent pas être accélérés. Mais presque tous peuvent être organisés de sorte que l'utilisateur puisse continuer à travailler. En .NET, cela se fait avec async et await : le calcul s'exécute dans un thread d'arrière-plan, l'interface reste utilisable, et le résultat revient ensuite dans le thread d'interface. Un exemple pour WPF :

private CancellationTokenSource abbruch;



private async void BerechnenButton_Click(object sender, RoutedEventArgs e)

{

    berechnenButton.IsEnabled = false;

    abbruch = new CancellationTokenSource();

    var fortschritt = new Progress<int>(prozent => fortschrittsBalken.Value = prozent);

    try

    {

        // Copier les données dans le thread d'interface, ne calculer en arrière-plan qu'avec la copie

        ModellDaten daten = modell.ErstelleKopie();

        Ergebnis ergebnis = await Task.Run(

            () => Berechnung.Starte(daten, fortschritt, abbruch.Token));

        ZeigeErgebnis(ergebnis);

    }

    catch (OperationCanceledException)

    {

        statusText.Text = "Berechnung abgebrochen.";

    }

    finally

    {

        berechnenButton.IsEnabled = true;

    }

}



private void AbbrechenButton_Click(object sender, RoutedEventArgs e)

{

    abbruch?.Cancel();

}

Important : en arrière-plan, le calcul ne doit toucher ni aux contrôles ni à la base de données de dessin d'un système de CAO. Il travaille sur une copie des données nécessaires et renvoie son résultat. Il signale sa progression via IProgress<T>. Comme l'objet Progress a été créé dans le thread d'interface, chaque notification y arrive. Le calcul vérifie régulièrement l'annulation via le CancellationToken.

Retour d'expérience : 12,5 à 15 fois plus rapide

Une entreprise avait développé elle-même son système de CAO et l'avait enrichi au fil des années de très nombreuses fonctions. Pour les constructions de grande taille, il fallait attendre plusieurs minutes une réaction – le système était pratiquement figé. L'objectif du client était de doubler la vitesse.

Nous avons examiné le logiciel et consigné les pistes d'amélioration dans un document de concept. Nous avons arrêté de compter à près de 50 points. Nous avons mis en œuvre nous-mêmes les mesures les plus efficaces. Au fil de plusieurs réunions, nous avons guidé le service logiciel du client pour qu'il mette lui-même en œuvre les autres points. Les calculs coûteux s'exécutent désormais en arrière-plan. Le résultat : au lieu du doublement espéré, le système est 12,5 à 15 fois plus rapide, mesuré sur les états intermédiaires. Là où les calculs se font en arrière-plan, les utilisateurs ne ressentent plus aucun délai.

Erreurs typiques

• Optimiser sans mesurer. Qui devine améliore souvent des endroits qui ne coûtent guère de temps.
• Mesurer avec de petites données de test. De nombreux freins n'apparaissent qu'avec de grands volumes de données.
• Bloquer sur le résultat au lieu de l'attendre de façon asynchrone. .Result ou .Wait() dans le thread d'interface bloquent à nouveau l'interface et peuvent provoquer des interblocages.
• async void en dehors des gestionnaires d'événements. Les exceptions ne peuvent pas y être interceptées. Utilisez sinon async Task.
• Accéder à l'interface ou à la base de données CAO depuis l'arrière-plan. Cela provoque des plantages sporadiques difficiles à trouver.
• Ne plus vérifier après l'optimisation. Sans mesures répétées ou tests automatisés, le logiciel redevient lent sans qu'on s'en aperçoive au fil des versions suivantes.
• Laisser le savoir-faire chez le prestataire. Si votre équipe comprend pourquoi quelque chose est devenu plus rapide, le logiciel restera rapide à l'avenir.

Sources : étude de cas « Système de CAO propriétaire : 12,5 à 15 fois plus rapide », études de cas Cadida ; Microsoft Learn : programmation asynchrone avec async et await.