Pourquoi boolean consomme plus de mémoire que char?

Question

Pourquoi un booléen consomme-t-il 4 octets et un caractère 2 octets dans le framework .NET? Un booléen doit prendre 1 bit ou au moins être plus petit qu'un caractère.

Answer 1

C’est une question d’alignement de la mémoire. Les variables de 4 octets fonctionnent plus rapidement que celles de 2 octets. C’est la raison pour laquelle vous devriez utiliser int au lieu de byte ou short pour les compteurs et autres.

Vous devez utiliser des variables de 2 octets uniquement lorsque la mémoire est une préoccupation plus importante que la vitesse. Et c’est la raison pour laquelle char (qui est Unicode dans .NET) prend deux octets au lieu de quatre.

Answer 2

À propos de booléen

La plupart des autres réponses se trompent - l'alignement et la rapidité sont les raisons pour lesquelles un programmeur doit s'en tenir aux compteurs de boucles int pour, pas pourquoi le compilateur peut faire en sorte qu'un octet ait une largeur de 4 octets. En fait, tous vos raisonnements s’appliquent aussi bien aux octets que les booléens.

Au moins en C #, bool (ou System.Boolean) est une structure intégrée de 1 octet de large, qui peut être automatiquement encadrée. Vous avez donc un objet (qui nécessite au minimum deux mots de mémoire). soit 8/16 octets sur des environnements 32/64 bits respectivement) avec un champ (au moins un octet) plus un mot de mémoire pour le pointer, c’est-à-dire au moins 13/25 octets.

Il s’agit bien de la première entrée Google dans les "Types primitifs C #". http://msdn.microsoft.com/en-us/ bibliothèque / ms228360 (VS.80) .aspx

Voir également le lien cité ( http://geekswithblogs.net/cwilliams /archive/2005/09/18/54271.aspx ) indique également qu'un booléen, au standard CLI, prend 1 octet.

En réalité, cependant, le seul endroit où cela est visible est sur les tableaux de booleans - n booleans prendraient n octets. Dans les autres cas, un booléen peut prendre 4 octets.

• À l'intérieur d'une structure, la plupart des environnements d'exécution (également en Java) alignent tous les champs sur une limite de 4 octets pour améliorer les performances. La JVM Monty pour les périphériques intégrés est plus sage - je suppose qu’elle réorganise les champs de manière optimale.
  • Sur la pile de trames / d'opérandes locale de l'interpréteur, dans la plupart des cas d'implémentation, une entrée de pile a une largeur de mot de mémoire (et peut-être que sur .NET, elle doit faire 64 bits de large pour prendre en charge double et long. sur .NET utilise seulement 1 entrée de pile au lieu de 2 en Java). Un compilateur JIT peut à la place utiliser 1 octet pour les locales booléennes tout en maintenant les autres vars alignés en réorganisant les champs sans impact sur les performances, si le surcoût supplémentaire en vaut la peine.

À propos de caractère

char sont deux octets car, lorsque la prise en charge de l'internationalisation est requise, l'utilisation de caractères deux octets en interne constitue le pari le plus sûr. Cela n’est pas directement lié au choix de prendre en charge l’Unicode, mais au choix de s’en tenir à UTF-16 et au plan multilingue de base. En Java et en C #, vous pouvez supposer tout le temps qu’un caractère logique s’inscrit dans une variable de type caractère.

Answer 3

En effet, dans un environnement 32 bits, la CPU peut gérer des valeurs 32 bits plus rapides que les valeurs 8 bits ou 16 bits. Il s’agit donc d’un compromis entre vitesse et taille. Si vous devez économiser de la mémoire et que vous avez beaucoup de bools, utilisez simplement les uint et enregistrez vos booléens sous forme de bits de 4 octets uint . Les caractères ont une largeur de 2 octets car ils stockent des caractères Unicode 16 bits.

Answer 4

Quelle que soit la différence mineure entre le stockage en mémoire, l’utilisation de Boolean pour les valeurs vrai / faux oui / non est importante pour les développeurs (y compris vous-même, lorsque vous devez revoir le code un an plus tard), car cela reflète plus précisément votre intention. Rendre votre code plus compréhensible est beaucoup plus important que de sauvegarder deux octets.

Rendre votre code plus fidèle à votre intention réduit également la probabilité que l'optimisation du compilateur ait un effet négatif. Ce conseil transcende les plates-formes et les compilateurs.

Answer 5

Vous devez également utiliser boolean pour vous aider à écrire du code maintenable. Si je jette un œil au code, je constate que quelque chose est un booléen vaut mieux que des économies de mémoire pour comprendre que vous utilisez char en tant que booléen.

Answer 6

J'ai trouvé ceci: "En réalité, un booléen correspond à 4 octets et non à 2. La raison en est que c'est ce que le CLR prend en charge pour les booléens. Je pense que c’est ce qu’il fait parce que les valeurs 32 bits sont beaucoup plus efficaces à manipuler. Le compromis temps / espace en vaut généralement la peine. Vous devez utiliser la classe de vecteur de bits (oubliez où il se trouve) si vous devez brouiller plusieurs bits ensemble ... "

Il a été écrit par Paul Wick à l'adresse http://geekswithblogs.net. /cwilliams/archive/2005/09/18/54271.aspx

Answer 7

Tout d’abord, vous devriez utiliser un profileur pour déterminer où vous avez un problème de mémoire, à mon humble avis.

Answer 8

La mémoire n'est un problème que si vous avez un grand tableau de bits, auquel cas vous pouvez utiliser la classe System.Collections.BitArray.

Answer 9

C’est parce que Windows et .Net ont utilisé Unicode (UTF 16) depuis leur création en tant que jeu de caractères interne. UTF 16 utilise 2 octets par caractère ou une paire de mots de 2 octets par caractère, mais uniquement Si nécessaire, il s'agit d'un codage à largeur variable .

" Pour les caractères du plan multilingue de base (BMP), le codage résultant est un mot unique de 16 bits. Pour les caractères des autres plans, le codage donnera une paire de mots de 16 bits "

Selon moi, les booléens sont composés de quatre octets, car le registre par défaut est de 32 bits et correspond à la taille minimale. Net pourrait effectuer une opération logique de manière efficace, à moins d’utiliser des opérations au niveau du bit.