71 votes

int ou Integer

Je dois créer un objet de transfert de données que je vais utiliser pour stocker les enregistrements extraits de la base de données. Dans cet objet de transfert de données, je dois déclarer un champ numérique. Pour ce que l'on est mieux - int ou Integer

Si je définis le champ comme Integer, cela aura-t-il un impact sur les performances en raison du type "Integer" si je vais extraire plus de 2000 enregistrements de DB!?

Merci d'avance.

141voto

Adeel Ansari Points 24434

Entier est une meilleure option, car il peut gérer la valeur null. Pour int null deviendrait 0, silencieusement. Ou même si non, vous ne pouvez pas faire grand-chose, comme int ne peut pas exprimer la valeur null.

La Performance est de peu d'intérêt ici.

  • Si vous choisissez de type int, vous allez finir par l'ajout de code de gestion d'un lot. Et il vous sera bénéfique rien à la fin. Votre code ne sera pas l'air propre et droit, beaucoup de chaudière-plaque de code, et vous n'auriez même pas de gain de performance.
  • Permettez-moi de préciser, pour les bases de données, la valeur null est pas le même que zéro. Parfois, vous finir par entrer 0, où null a été prévu. Imaginez le cas où l'utilisateur a soumis un formulaire, et ne fournit aucune valeur de type int. Vous finirez par arriver à 0 par défaut. Il est logique, lorsque ce champ n'est pas null dans la base de données, mais qui sait, vous pourriez refactoriser votre table, en bas de la route, pour faire que l' nullable.

23voto

MrWiggles Points 6622

Vous devriez vraiment prendre votre décision basée sur ce que vous avez besoin de votre objet à faire, plutôt que les coûts de l'exécution. Décider sur la base des performances devrait être fait une fois une question de vitesse a été identifié avec un profileur de - la racine de tout mal et de tout ce qui.

Regardez quelques-unes des caractéristiques des deux et l'utiliser pour votre décision, par exemple

Entier peut être null, int ne peut pas (donc l'int dans la DB NULLable champ?) Avez-vous besoin de l'accès à l'Entier les méthodes de la classe? Faites-vous de l'arithmétique?

Personnellement, j'opte toujours pour la primiive sur l'emballage mais c'est juste une préférence chose plutôt que basée sur la technique du mérite

12voto

Andrzej Doyle Points 52541

À mon avis, le choix entre la déclarer que quelque chose comme int ou Entier revient simplement à savoir si la valeur null est une valeur valide ou non. L'autoboxing (et autounboxing) va prendre soin de tous les problèmes de conversion où le nombre doit tout simplement être un type ou d'un autre. La Performance (comme cela a été souligné) est également peu probable pour être perceptible dans presque tous les cas.

En outre, int devrait être le choix naturel, et est susceptible d'être le plus performant, qui devrait être un problème de toute façon. Si vous avez besoin d'être capable de stocker les valeurs null, alors vous avez à utiliser Entier (et également s'assurer qu'aucune des références nulles sont auto-unboxed pour une méthode qui prend simplement ints cela se traduira par une NullPointerException).

5voto

Mehrdad Afshari Points 204872

Integer est théoriquement plus lent que int , cependant, l'impact sur les performances devrait être minime, sauf si vous calculez des chiffres. Les optimisations JIT réduiront également la perte de performance.

Utilisez celui qui convient le mieux à votre situation en termes de type primitif ou de type référence.

4voto

Amine Points 99

int est 10 fois plus rapide qu'un entier

nous testons ce code avec la bibliothèque de performances de Jetm

 int n;
EtmPoint point1 = etmMonitor.createPoint("test:objects");
for (n = 0; n < 1000000; n++) {
    Integer t = 0;
    t = 10;
    t = 11;
}

point1.collect();
EtmPoint point = etmMonitor.createPoint("test:primitives");
for (n = 0; n < 1000000; n++) {
    int t = 0;
    t = 10;
    t = 11;
}
point.collect();

etmMonitor.render(new SimpleTextRenderer());
 

et les résultats:
test: objets 10.184
test: primitives 1.151

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X