ToOnS a dit : "cool alors ca veut dire aussi que t'as compris que un integer ou un uinteger ca tien sur 4 octets en memoire et que comme on a tous que 256ko de memoire (ben quoi j'ai un vieux pc) si tu veux compter jusque 100 faut pas utiliser un integer mais plutot un byte (qui va jusque 255) qui prend que un octet de memoire donc tu sauves 3 octets de ma petite ram
ou alors tu consideres qu'on a tous au moins 2Go de ram et que dans ce cas 3 octets d'economisés on s'en tape et tu utilises quand meme un integer"
En fait, c'est même pire que ça.
Sur les processeurs actuels (32 bits et 64 bits), c'est souvent plus performant de traiter des données sur 32 bits que des données sur 8 ou 16 bits.
Ainsi, une structure du genre :
struct S1
{
char prefix; // 1 octet
int data1; // 4 octet
int data2; // 4 octet
int data3; // 4 octet
}
sera le plus souvent moins performante que :
struct S2
{
int prefix;
int data1;
int data2;
int data3;
}
car dans le premier cas, data1, data2 et data3 ne sont pas correctement alignés sur des mots de 32 bits. Ainsi pour accéder à S1.data2 par exemple, il va falloir lire deux mots de 32 bits et reconstituer la donnée requise. Alors que S2.data2 est directement accessible car correctement aligné.
C'est une des raisons pour lesquelles il est conseillé d'utiliser par défaut le type int en C / C++ / C#..., qui correspond à l'entier géré nativement par le processeur (16 bits minimum).
Ceci dit, comme on est dans la partie "VB", à priori on s'en tape un peu de l'optimisation...