Je dois stocker des millions de paires de deux paires x / y à titre de référence dans mon programme Java. Je voudrais conserver la consommation de mémoire aussi bas que possible que le nombre de références d'objet. Ainsi, après quelques pensées, j'ai décidé de tenir les deux points dans un minuscule tableaux double pourriez-vous être une bonne idée, sa configuration ressemble à:
class Node {
public double x, y;
}
3 Réponses :
Ce dernier a l'empreinte plus petite.
Les types primitifs sont stockés en ligne dans la classe contenant. Donc, votre noeud Si vous allez allouer 100 variables de cette façon, cela n'a pas beaucoup d'importance, car il ne s'agit que de la taille de l'en-tête qui sont différentes.
CAVEAT: Tout cela est quelque peu spéculatif car vous n'avez pas spécifié le JVM - Certains de ces détails peuvent varier de JVM. nécessite un en-tête d'objet et deux emplacements 64 bits. La matrice que vous spécifiez utilise une en-tête de tableau (> = un en-tête d'objet) Plust deux emplacements 64 bits.
Actuellement exécutant Java 1.7 SE en X64 sur Mac OS X. Maintenant, je suppose qu'un tableau 2D géant éliminerait la référence d'objet nécessaire pour chaque noeud entièrement, ce qui serait donc de loin la plus grande mémoire conservatrice?
Si, par 2D, vous voulez dire double [2] [n] ou double [n] [2], cela conduira également à des références d'objet. Étant donné que les tableaux en Java sont vraiment des matrices de matrices dans ce cas
(Vous êtes Way surroplizant cela, mais ...) L'empreinte de la moindre mémoire serait un tableau 1-D dans lequel vous calculez explicitement les index explicitement. Les tableaux 2D en Java ne sont que un éventail de pointeurs vers des tableaux 1D.
Je vous suggère de simplement créer un nœud avec une carte d'identité longue, double X, double Y, le rendre comparable par ID et insérez-les dans un arbre lorsque vous les lisez de la base de données.
Arbreset vous donnera un journal (n) mais dans ce cas, il devrait suffire de ne pas être relativement faible et que les opérations sont bon marché.
Donc, depuis que des matrices de 1-D semblent être la voie à suivre, que si je faisais trois matrices 1-D, l'un étant de type long (pour l'ID) et deux doubles (pour X & Y), ma base de données est capable d'apporter Les données de mon application dans mon application en utilisant l'instruction SQL "commande par", ainsi que les données sont déjà triées pour moi. Cela me permettrait d'écrire une recherche binaire en utilisant une matrice d'identification et une fois mon noeud, cet index peut être utilisé sur les deux autres tableaux pour aller chercher les points X et Y. Tout cela ne prenant que trois références d'objets, comment ça sonne?
Je ne pense pas que votre plus grand problème va stocker les données, je pense que cela va être récupérer, indexer et le manipuler.
Cependant, un tableau, fondamentalement, est la voie à suivre. Si vous souhaitez économiser sur les pointeurs, utilisez un tableau unidimensionnel. (Quelqu'un a déjà dit cela).
Tout d'abord, il faut indiquer que l'utilisation de l'espace réelle dépend de la JVM que vous utilisez. C'est strictement la mise en œuvre spécifique. Ce qui suit est pour un JVM traditionnel typique.
La question est-elle, qui a une empreinte de mémoire plus petite? Et pourquoi?
La 2e version est plus petite. Un tableau a la surcharge du champ 32 bits dans l'en-tête d'objet qui contient la longueur de la matrice. Dans le cas d'un objet non-réseau, la taille est implicite dans la classe et n'a pas besoin d'être représentée séparément.
MAIS Notez qu'il s'agit d'une tête fixe sur la tête par objet de tableau . Plus le tableau est important, moins les frais généraux sont pratiques. Et le flipside d'utiliser une classe plutôt que de la matrice est que l'indexation ne fonctionnera pas et que votre code peut être plus compliqué (et plus lent).
Un tableau 2D Java 2D est en fait et une matrice de tableaux 1D (etc.), vous pouvez donc appliquer la même analyse aux tableaux avec une dimensionnalité plus élevée. Plus la taille de la taille est une matrice dans n'importe quelle dimension, moins l'impact sur les frais généraux. Les frais généraux dans un tableau
2x10 seront inférieurs à un tableau10x2 . (Pensez-le ... 1 Tableau de longueur 2 + 2 de longueur 10 Versus 1 matrice de longueur 10 + 10 de longueur 2. La surcharge est proportionnelle au nombre de matrices.)Je suis particulièrement intéressé par la question de savoir si les champs de classe utilisent ou non un pointeur, et ont donc une surcharge de 32 bits, ou non.
(vous parlez réellement de champs d'instance, pas de champs de classe. Ces champs ne sont pas
statique ...)champs dont le type est un type primitif sont stockés directement dans le nœud de tas de l'objet sans aucune référence. Il n'y a pas de surcharge de pointeur dans ce cas.
Cependant, si les types de champ étaient des types d'emballage (par exemple,
double plutôt quedouble ), il pourrait y avoir la surcharge d'une référence et les frais généraux de l'en-tête de l'objet pour ledouble objet.