Pourquoi devrais-je utiliser int au lieu de byte ou short en C# ?

Question

J'ai trouvé quelques fils de discussion concernant ce problème. La plupart des gens semblent préférer l'utilisation d'int dans leur code C#, même si un byte ou un smallint peut gérer les données, sauf s'il s'agit d'une application mobile. Je ne comprends pas pourquoi. Ne serait-il pas plus logique de définir votre type de données C# comme le même type de données que celui de votre solution de stockage de données ?

Ma prémisse : Si j'utilise un ensemble de données typées, des classes Linq2SQL, POCO, d'une manière ou d'une autre, je rencontrerai des problèmes de conversion de type de données dans le compilateur si je ne garde pas mes types de données en synchronisation avec mes niveaux. Je n'aime pas vraiment faire System.Convert tout le temps juste parce qu'il était plus facile d'utiliser int dans tout le code C#. J'ai toujours utilisé le plus petit type de données nécessaire pour gérer les données dans la base de données ainsi que dans le code, afin de garder mon interface avec la base de données propre. Je parierais donc que 75% de mon code C# utilise byte ou short plutôt que int, parce que c'est ce qui se trouve dans la base de données.

Possibilités : Cela signifie-t-il que la plupart des personnes qui utilisent int pour tout dans le code utilisent également le type de données int pour leurs types de données de stockage sql et ne se soucient pas de la taille globale de leur base de données, ou font-ils system.convert dans le code chaque fois que cela est possible ?

Pourquoi ça m'intéresse : J'ai toujours travaillé à mon compte et je veux simplement me familiariser avec les meilleures pratiques et les conventions de codage standard.

Answer 1

En termes de performances, un int est plus rapide dans presque tous les cas. Le processeur est conçu pour travailler efficacement avec des valeurs de 32 bits.

Les valeurs plus courtes sont compliquées à gérer. Pour lire un seul octet, par exemple, le CPU doit lire le bloc de 32 bits qui le contient, puis masquer les 24 bits supérieurs.

Pour écrire un octet, il doit lire le bloc de 32 bits de destination, écraser les 8 bits inférieurs avec la valeur d'octet souhaitée et réécrire l'ensemble du bloc de 32 bits.

En termes d'espace, bien sûr, vous économisez quelques octets en utilisant des types de données plus petits. Ainsi, si vous construisez une table de quelques millions de lignes, il peut être intéressant d'envisager des types de données plus courts. (Et c'est aussi une bonne raison d'utiliser des types de données plus petits dans votre base de données).

Et du point de vue de la correction, un int ne déborde pas facilement. Et si vous pensez à votre valeur va tenir dans un octet, et puis à un moment donné dans le futur, une modification inoffensive du code signifie que des valeurs plus grandes sont stockées dans le code ?

Ce sont quelques-unes des raisons pour lesquelles int devrait être votre type de données par défaut pour toutes les données intégrales. N'utilisez byte que si vous voulez réellement stocker des octets machine. N'utilisez les shorts que si vous avez affaire à un format de fichier, un protocole ou autre qui spécifie des valeurs entières de 16 bits. Si vous avez affaire à des entiers en général, faites-en des ints.

Answer 2

Il faudrait avoir affaire à quelques MILLIARDS de lignes pour que cela fasse une différence significative en termes de capacité de stockage. Supposons que vous ayez trois colonnes et qu'au lieu d'utiliser un type de base de données équivalent à un octet, vous utilisiez un équivalent à un int.

Cela nous donne 3 (colonnes) x 3 (octets supplémentaires) par ligne, soit 9 octets par ligne.

Cela signifie que, pour "quelques millions de lignes" (disons trois millions), vous consommez 27 mégaoctets supplémentaires d'espace disque ! Heureusement, comme nous ne vivons plus dans les années 1970, vous ne devriez pas avoir à vous soucier de cela :)

Comme nous l'avons dit plus haut, arrêtez de faire de la micro-optimisation - la perte de performance lors de la conversion vers/depuis différents types numériques de type entier va vous frapper beaucoup, beaucoup plus fort que les coûts de bande passante/espace disque, à moins que vous ne traitiez de très, très, très grands ensembles de données.

Answer 3

Pour la plupart, "non".

À moins que vous ne sachiez d'avance que vous allez traiter des centaines de millions de lignes, il s'agit d'une micro-optimisation.

Faites ce qui correspond le mieux au modèle du domaine. Par la suite, si vous rencontrez des problèmes de performance, effectuez des analyses comparatives et établissez des profils pour déterminer avec précision où ils se produisent.

Answer 4

Ce n'est pas que je ne croyais pas Jon Grant et d'autres, mais je devais voir par moi-même avec notre "million row table". La table a 1 018 000 lignes. J'ai converti 11 colonnes tinyint et 6 colonnes smallint en int, il y avait déjà 5 int et 3 smalldatetimes. 4 index différents utilisaient une combinaison des différents types de données, mais évidemment les nouveaux index utilisent tous des colonnes int.

Les modifications apportées ne m'ont coûté que 40 Mo en calculant l'utilisation du disque de la table de base, sans index. Lorsque j'ai rajouté les index, la différence globale n'était que de 30 Mo. J'ai été surpris car je pensais que la taille de l'index serait plus importante.

Alors, est-ce que 30 mb vaut la peine d'utiliser tous les différents types de données, pas question ! Je m'en vais au pays de l'INT, merci à tous d'avoir remis ce programmeur réticent sur le droit chemin d'une vie heureuse et béate où il n'y a plus de conversions d'entiers... yippeee !

Answer 5

Le runtime .NET est optimisé pour Int32. Voir la discussion précédente à .NET Integer vs Int16 ?