Comment : améliorer les performances
Mise à jour : novembre 2007
Les méthodes de programmation suivantes permettent d'économiser de la mémoire et d'améliorer les performances des applications Smart Device.
Pour économiser de la mémoire avec les Windows Forms et les graphiques
Utilisez les méthodes BeginUpdate et EndUpdate sur les contrôles qui les proposent, tels que ComboBox, ListBox, ListView, ToolStripComboBox et TreeView.
Utilisez les méthodes SuspendLayout et ResumeLayout lors du repositionnement des contrôles.
Chargez d'autres formulaires en arrière-plan et remplissez les contrôles avec des données avant d'utiliser la méthode Show().
Limitez le code de gestion des événements pour effectuer uniquement les tâches essentielles, afin que les processus en attente puissent continuer.
Avant d'éliminer un objet abonné, annulez l'abonnement à ses événements à l'aide de l'opérateur d'assignation de soustraction. Pour plus d'informations, consultez Comment : s'abonner et annuler l'abonnement à des événements (Guide de programmation C#). Les problèmes résultant de l'annulation incorrecte d'un abonnement peuvent être similaires à une fuite de mémoire.
Utilisez une bitmap hors écran. Pour obtenir un exemple, consultez Comment : dessiner des images hors écran.
Substituez les méthodes OnKeyDown, OnKeyPress et OnKeyUp sur les contrôles au lieu d'ajouter des gestionnaires d'événements de touche.
Pour économiser de la mémoire avec les données et les chaînes
Utilisez des variables entières (Int32 ou Int64) dans les boucles for au lieu de variables objets.
Évitez d'employer la méthode ToString d'une énumération, car elle nuit aux performances en effectuant des recherches dans les tables de métadonnées.
Évitez les erreurs OutOfMemoryException. Cette exception peut être levée par le Common Language Runtime lorsqu'il n'y a pas suffisamment de mémoire à allouer à des fins internes ou pour de nouvelles instances d'objet. Pour éviter cette exception, évitez de programmer de vastes méthodes qui consomment 64 Ko de mémoire ou davantage.
Supprimez System.SR.dll qui contient des chaînes de message d'erreur pour les boîtes de dialogue d'exception. Vous pouvez déployer votre application sans ce fichier pour économiser de la mémoire. .NET Compact Framework charge dynamiquement les chaînes d'erreur contenues dans System.SR.dll si le fichier est présent.
Si ce fichier .dll n'est pas présent sur le périphérique, toutes les exceptions contiennent le message « Assembly de ressource introuvable ». Pendant le développement, toutefois, il est utile d'ajouter à votre projet Visual Studio une référence à System.SR.dll pour voir les exceptions significatives.
Les chaînes étant immuables, un objet String est créé chaque fois que vous modifiez la chaîne. Envisagez d'utiliser StringBuilder lors de la construction d'une chaîne qui sera souvent modifiée.
Utilisez la méthode ParseExact pour DateTime si vous connaissez le format exact utilisé pour la sérialisation DateTime. Sinon, l'analyseur DateTime essaiera séquentiellement d'appliquer plusieurs formats spécifiques à la culture.
Limitez le nombre d'objets SqlCeCommand ouverts et supprimez-les lorsque vous avez fini.
Pour économiser de la mémoire lors de l'interaction avec le code natif
Dans les opérations d'appel de code non managé, utilisez des types blittables qui ont une représentation commune à la fois dans la mémoire managée et non managée, par exemple Int32 ou IntPtr. Les types valeur blittables supérieurs à 32 bits sont passés plus rapidement par référence que par valeur. Pour plus d'informations sur les types blittables, consultez Types blittables du .NET Compact Framework.
Utilisez les attributs InAttribute et OutAttribute pour les arguments dans votre signature de fonction pour réduire le marshaling inutile.
Utilisez les méthodes dans la classe Marshal pour effectuer une conversion manuelle entre IntPtr et les objets managés, tels que PtrToStructure, PtrToStringBSTR, GetObjectForNativeVariant et GetObjectForIUnknown.
Utilisez les méthodes Prelink et PrelinkAll pour entraîner la compilation JIT du stub qui prend en charge les appels entre le code natif et le code managé.
Si vous attendez que votre objet COM natif retourne S_FALSE comme c'est souvent le cas, ou d'autres valeurs différentes de S_OK HRESULT, affectez au champ PreserveSig la valeur true et établissez une correspondance entre la signature managée et la signature native. Vous évitez ainsi la charge mémoire d'un bloc try/catch nécessaire lorsque le runtime traduit des valeurs HRESULT en exceptions sur vos appels COM.
Effectuez le plus de tâches possible lors d'un appel de code non managé plutôt que d'avoir recours à plusieurs appels.
Pour économiser de la mémoire dans les collections
Utilisez des indexeurs si la collection est basée sur un tableau.
Dès que possible, spécifiez la taille de votre collection, car un redimensionnement dynamique peut augmenter considérablement le stockage excédentaire.
Utilisez des collections génériques pour éviter la charge mémoire des conversions boxing et unboxing pour les types valeur. Vous obtenez les meilleures performances possibles en définissant votre propre collection optimisée.
Pour économiser de la mémoire en XML
Utilisez XmlTextReader et XmlTextWriter au lieu de XmlDocument, qui utilise plus de mémoire.
Spécifiez des paramètres pour XmlReaderSettings et XmlWriterSettings pour améliorer les performances. Les valeurs des propriétés IgnoreWhitespace et IgnoreComments, le cas échéant, peuvent améliorer considérablement les performances.
Utilisez les codages de caractères UTF-8, ASCII et UTF-16, qui sont plus rapides que les codages de page de codes ANSI et Windows.
Évitez d'utiliser un schéma pour l'analyse, car il requiert un travail de validation supplémentaire.
Mappez des colonnes comme attributs et utilisez un DataSet typé lors du remplissage d'un DataSet à partir d'une source XML.
Évitez les éléments suivants lors du remplissage d'un DataSet :
Les indications suivantes améliorent les performances lors de l'utilisation de la désérialisation XML :
Faites en sorte que les noms d'éléments et d'attributs soient aussi courts que possible car chaque caractère doit être validé.
Le code XML basé sur les données d'attributs est plus rapide que le code XML basé sur les données d'éléments.
Utilisez la méthode XmlNodeReader.Skip lorsque cela est possible.
Envisagez la sérialisation binaire lorsque les performances deviennent critiques.
Utilisez une instance XmlSerializer par type pour la sérialisation XML pour réduire le temps passé à rechercher des métadonnées.
Dans la mesure où la sérialisation de grandes quantités de code XML peut monopoliser la mémoire, envisagez de générer à la place un mécanisme de sérialisation binaire personnalisé en utilisant BinaryReader et BinaryWriter.
Pour économiser de la mémoire lors de l'utilisation d'un service Web
Utilisez un DiffGram lorsque vous lisez et écrivez DataSet. Pour plus d'informations, consultez DiffGrams (ADO.NET).
Enregistrez un DataSet distant et son schéma sur le périphérique en tant que XML.
Effectuez un simple appel de méthode de service Web lorsque l'écran de démarrage apparaît, car le premier appel est plus lent que les appels suivants.
Veillez à gérer les erreurs relatives au réseau et aux données.
Dans certains cas, la sérialisation manuelle de DataSet en tant que chaîne XML avant d'effectuer un appel à un service Web améliore les performances.
Pour économiser de la mémoire dans la programmation avancée
Traitez les opérations de grande envergure de manière asynchrone.
Évitez les appels virtuels. Les appels virtuels du runtime .NET Compact Framework sont approximativement 30 pour cent plus lents que les appels statiques ou d'instance. .NET Compact Framework n'utilise pas vtables en raison de ressources limitées et les méthodes doivent donc être appelées en traversant la hiérarchie des interfaces et des classes, ce qui est une opération coûteuse. .NET Compact Framework conservant un cache des appels virtuels résolus, la plupart des appels ne doivent pas être réinterprétés.
Utilisez des champs au lieu de propriétés lorsque cela est possible.
Substituez les méthodes GetHashCode et Equals lors de la définition d'un type valeur. Si elles ne sont pas substituées, le runtime utilise des versions généralisées pour ces méthodes dans la classe ValueType de base.
Utilisez la réflexion avec précaution. L'utilisation de la réflexion à des fins d'investigation avec des classes non instanciées peut avoir un impact sur les performances des objets instanciés dans votre application.
Vérifiez que vos ressources managées ont des noms de types qualifiés complets et sont exactes dans votre fichier RESX. Elles doivent posséder la version appropriée et les champs PublicKeyToken. L'effort de rechercher la substitution la plus appropriée pour un type spécifié de façon incorrecte a un impact sur les performances.
Notez que, dans certains cas, la lecture des données d'application directement à partir du fichier peut être suffisante et plus efficace qu'à l'aide de ResourceManager. ResourceManager peut examiner plusieurs emplacements dans le système de fichiers pour trouver le meilleur assembly satellite correspondant avant de localiser votre binaire de ressource. Utilisez les outils appropriés pour le travail.
Voir aussi
Concepts
Gestion de la mémoire des appareils dans le .NET Compact Framework
.Rubriques Comment relatives au .NET Compact Framework