Parmi les nombreuses techniques permettant d'optimiser la taille du code d'un programme, la plupart incluent la suppression des éléments inutiles du code. Visual Basic supprime automatiquement certains éléments lors de la compilation d'une application. Il n'y a aucune restriction sur la longueur ou le nombre de noms d'identifiant, de commentaires et de lignes vides. Lorsque l'application est exécutée en tant que fichier .EXE, ces éléments n'affecteront pas la taille de la mémoire occupée par l'application. D'autres éléments, tels que les variables, les formulaires et les procédures, occupent de l'espace en mémoire. Il vaut mieux les rationaliser pour les rendre plus efficaces. Ce qui suit présente 6 méthodes qui peuvent être utilisées pour réduire la mémoire requise par l'application et réduire la taille du code. J'espère que cela sera utile aux débutants.
1. Réduisez le nombre de formulaires et de contrôles de chargement et utilisez des étiquettes au lieu de zones de texte
Chaque formulaire chargé, qu'il soit visible ou non, occupe une certaine quantité de mémoire (cette quantité varie en fonction du type et du nombre de contrôles sur le formulaire, de la taille du bitmap sur le formulaire, etc.). Chargez le formulaire uniquement lorsque vous devez l'afficher et déchargez-le lorsqu'il n'est plus nécessaire (plutôt que de masquer le formulaire). N'oubliez pas que toute référence aux propriétés, méthodes ou contrôles d'un formulaire, ou à une variable de formulaire déclarée avec New, entraînera le chargement du formulaire par Visual Basic.
Lorsque vous utilisez la méthode Unload pour décharger un formulaire, seule une partie de l'espace occupé par le formulaire peut être libérée. Pour libérer tout l'espace, utilisez le mot-clé Nothing pour invalider la référence du formulaire :
Lors de la conception d’une application, les formulaires doivent utiliser le moins de contrôles possible. La limite réelle dépend du type de contrôle et du système, mais en pratique, un formulaire comportant un grand nombre de contrôles s'exécutera lentement. Une technique connexe consiste à utiliser des tableaux de contrôles autant que possible lors de la conception, plutôt que de placer un grand nombre de contrôles du même type sur le formulaire. Un tableau de contrôles est un groupe de contrôles ayant un nom et un type communs. Leur déroulement est également le même. Au moment de la conception, l’ajout de contrôles à l’aide d’un tableau de contrôles consomme moins de ressources que l’ajout de plusieurs contrôles du même type directement au formulaire. Les tableaux de contrôles sont également utiles lorsque vous souhaitez que plusieurs contrôles partagent du code. Le contrôle d'étiquette Label consomme moins de ressources Windows que la zone de texte Textbox. Par conséquent, lorsque cela est possible, une étiquette doit être utilisée à la place d'une zone de texte. Par exemple, lorsqu'un contrôle masqué sur un formulaire doit contenir du texte, l'utilisation d'étiquettes est plus efficace.
2. Utilisez des fichiers disque ou des ressources et des modules d'organisation
Les données placées directement dans l'application au moment de la conception (telles que les chaînes littérales et les valeurs dans les propriétés ou le code) augmenteront la mémoire occupée par l'application au moment de l'exécution. Le chargement de données à partir de fichiers disque ou de ressources au moment de l'exécution réduit l'utilisation de la mémoire. Ceci est particulièrement utile pour les bitmaps et les chaînes volumineux. Les fichiers de ressources sont en fait composés d'une série de chaînes indépendantes, de bitmaps ou d'autres éléments, chacun possédant un identifiant unique. Les fichiers de ressources peuvent être créés à l'aide d'un éditeur de texte et d'un compilateur de ressources similaires à ceux fournis dans Microsoft Visual C. Les fichiers de ressources compilés ont une extension .res.
Visual Basic charge les modules uniquement lorsque cela est nécessaire, c'est-à-dire que lorsque le code appelle une procédure dans le module, le module est chargé en mémoire. Si une procédure dans un module particulier n'est jamais appelée, Visual Basic ne charge jamais le module. Par conséquent, essayez de placer les procédures associées dans le même module et laissez Visual Basic charger le module uniquement en cas de besoin.
3. Pensez à remplacer le type de données Variant
Le type de données Variant est extrêmement flexible à utiliser, mais occupe plus de mémoire que les autres types de données. Lorsque vous souhaitez compresser l'espace excédentaire dans votre application, vous devez envisager de remplacer les variables Variant par d'autres types de données, en particulier en remplaçant les tableaux de variables Variant.
Chaque variante occupe 16 octets, tandis que Integer occupe 2 octets et Double occupe 8 octets. Une variable chaîne de longueur variable occupe 4 octets plus 1 octet pour chaque caractère de la chaîne. Cependant, chaque Variant contenant une chaîne occupe 16 octets plus 1 octet pour chaque caractère de la chaîne. En raison de leur taille importante, les variables Variant sont particulièrement ennuyeuses lorsqu'elles sont utilisées comme variables locales ou comme arguments de procédures, car elles consomment trop rapidement de l'espace dans la pile. Mais dans certains cas, l’utilisation d’autres types de données au lieu de Variant réduit la flexibilité, et davantage de code doit être ajouté pour compenser la perte de flexibilité. Le résultat n’est pas une réelle réduction de taille.
4. Utilisez des tableaux dynamiques et récupérez de la mémoire lors de la suppression
Utilisez des tableaux dynamiques au lieu de tableaux fixes. Lorsque les données du tableau dynamique ne sont plus nécessaires, utilisez Erase ou ReDimPReserve pour supprimer les données inutiles et récupérer la mémoire utilisée par le tableau. Par exemple, utilisez le code suivant pour récupérer l'espace utilisé par un tableau dynamique :
Ici, Erase supprime complètement le tableau, tandis que ReDimPreserve raccourcit uniquement le tableau sans perdre son contenu :
La suppression d'un tableau de taille fixe ne récupère pas l'espace occupé par le tableau : elle efface simplement la valeur de chaque élément du tableau. Si les éléments sont des chaînes ou des variantes contenant des chaînes ou des tableaux, la suppression du tableau récupère la mémoire occupée par ces chaînes ou variantes, et non la mémoire occupée par le tableau lui-même.
5. Récupérer l'espace utilisé par les variables de chaîne ou d'objet
Lorsque le processus se termine, l'espace utilisé par les variables de chaîne et de tableau locales (non statiques) peut être automatiquement récupéré. Cependant, les variables de chaîne et de tableau globales et au niveau du module survivent jusqu'à la fin du programme entier. Si vous souhaitez que votre application soit la plus petite possible, vous devez récupérer autant que possible l'espace utilisé par ces variables. L'attribution d'une chaîne de longueur nulle à une variable chaîne récupère son espace :
De même, définir une variable d'objet sur Nothing récupère une partie (mais pas la totalité) de l'espace utilisé par l'objet. Par exemple, pour supprimer une variable d'objet Form :
Même si vous n'utilisez pas de variables de formulaire explicites, vous devez veiller à décharger les formulaires qui ne sont plus utilisés, plutôt que de simplement les masquer.
6. Éliminez le code mort et les variables inutiles
Au fur et à mesure que vous développez et modifiez votre application, vous risquez de vous retrouver avec du code mort, c'est-à-dire un processus complet dans votre code qui n'est appelé nulle part. Certaines variables inutilisées peuvent également être déclarées. Bien que Visual Basic puisse effectivement supprimer les constantes inutiles lors de la création de fichiers .exe, il ne peut pas supprimer les variables inutiles et le code mort. Soyez prudent de revoir votre code pour trouver et supprimer les variables inutiles et le code mort. Par exemple, l'instruction Debug.Print est ignorée lors de l'exécution de .exe, mais elle apparaît souvent dans les fichiers .exe.
Lors de la création d'un fichier .exe, les instructions Debug.Print contenant des chaînes et des variables comme paramètres ne sont pas compilées. Mais pour l'instruction Debug.Print qui contient une fonction comme paramètre, elle est elle-même ignorée par le compilateur et la fonction est compilée. Ainsi, pendant l'exécution de l'application, la fonction est appelée mais la valeur de retour est ignorée. Parce que dans le fichier .exe, lorsque la fonction apparaît comme paramètre de Debug.Print, elle prendra de l'espace et du temps de cycle CPU, il est donc préférable de supprimer ces instructions avant de générer le fichier exe.
Utilisez la commande Rechercher du menu Edition pour rechercher des références à une variable spécifique. Ou lorsque chaque module contient une instruction OptionExplicit, vous pouvez rapidement découvrir si la variable est utilisée en supprimant ou en commentant la déclaration de la variable et en exécutant l'application. Si cette variable est utilisée, Visual Basic générera une erreur. Si aucune erreur ne se produit, la variable n'est pas utilisée. ->