Profilage de mémoire avec des questions DotTrace

Question

J'ai couru dotTrace sur mon application (qui a quelques problèmes). Ce sont les deux principales fonctions qui sont apparues, en prenant environ 94% du temps d'application. Comme je ne connaissais pas ces deux fonctions, j'ai parcouru mon code ligne par ligne. Il fonctionne en douceur et efficacement jusqu'à un point où il se bloque. "newFrm.Show()".

Le fichier newFrm contient uniquement une zone de texte. Plus le fichier que je charge dans la zone de texte est grand (c'est un programme de bloc-notes), plus il prend de temps. Normalement, cela a du sens, mais cela prend environ 30 secondes pour un fichier de 167 Ko.

Maintenant, je ne sais pas quoi faire. Il fonctionne incroyablement lentement/cesse de fonctionner lorsque vous chargez un fichier texte et essayez de redimensionner la fenêtre contenant le fichier texte aussi. Puis j'ai réalisé qu'il ne réussit qu'à ouvrir des fichiers texte avec une longue chaîne de caractères hexadécimaux à l'intérieur (par exemple) "XX-XX-XX-" etc. Avec d'autres fichiers de taille similaire, il a du mal à redimensionner, mais s'ouvre à l'intérieur quelques secondes.

Est-ce que cela a quelque chose à voir avec les propriétés de la zone de texte? Je l'ai mis en multiline et ai mis maximum de caractères à 0 (donc illimité).

Comment résoudre ce problème? Y a-t-il un moyen de voir ce qu'on appelle dans ces fonctions?

Answer 1

Il est normal qu'un profileur montre que la plupart des exécutions ont lieu dans ces appels API Windows. CallWindowProc() exécute le gestionnaire de message par défaut pour un contrôle, vous mesurez le temps nécessaire pour le contrôle de zone d'édition native intégré dans Windows pour gérer votre fichier texte. WaitMessage() tourne, en attendant un message de Windows que quelque chose d'intéressant est arrivé. Cela rend le code de l'interface graphique difficile, vous devez soulever le code que vous avez écrit dans un programme de style de test unitaire. Pas pratique ici, vous n'avez pas écrit le code qui prend tous les cycles du processeur.

Votre problème est que TextBox n'est pas un très bon éditeur de texte. Il n'a aucune des optimisations que vous trouverez dans un éditeur à part entière. Veillez à désactiver la propriété WordWrap, ce qui est particulièrement coûteux. Et assurez-vous de ne pas remplir TextBox ligne par ligne à partir d'un fichier, c'est très lent comme le contrôle natif doit constamment réaffecter son tampon. Utilisez File.ReadAllText() ou utilisez un StringBuilder, puis affectez Text.

Quelque chose comme l'open source ScintillaNET fait un bien meilleur travail.