Existe-t-il une différence de bas niveau entre int [large] [petit] ou int [petit] [grand] en Java?

Question

Cette question nécessitera probablement quelques connaissances du compilateur. Je travaille actuellement sur un projet où je créerai un tableau qui pourrait être soit

 int[2][veryLargeNumber]
 

ou

 int [veryLargeNumber][2]
 

Logiquement, cela ne fait aucune différence, mais je pensais que la forme (et donc la taille) de la mémoire pouvait être différente (la question devrait peut-être être de savoir si les compilateurs sont assez intelligents pour réorganiser les tableaux à leur convenance)?

Answer 1

Java n'implémente unique dimensions des tableaux. Il est multi-dimensionnelle types, cependant deux dimensions des tableaux sont effectivement mis en œuvre comme un tableau de tableaux. Chaque tableau a une surcharge de près de 16 octets. Vous êtes mieux avec int[2][x] afin de minimiser les frais généraux.

Vous pouvez éviter ce problème entièrement à l'aide des méthodes d'assistance.

final int[] array = new int[2 * veryLargeNumber];

public int get(int x, int y) {
    return array[idx(x, y)];
}

public void set(int x, int y, int val) {
    array[idx(x, y)] = val;
}

private int idx(int x, int y) {
    return x * 2 + y; // or x * veryLargeNumber + y;
}

Afin de fournir ce pour vous-même, chaque objet de hachage unique, de générer des hashCode qui est stocké dans son en-tête Objet.

Vous pouvez voir à partir de http://ideone.com/oGbDJ0 que chaque tableau imbriqué est un objet en soi.

int[][] array = new int[20][2];
for (int[] arr : array) {
    System.out.println(arr);
}

imprime la représentation interne d'un int[] qui [I suivie par @ , suivi par le hashCode() stockées dans l'en-tête. Ce n'est pas comme certains le pensent, l'adresse de l'objet. L'adresse ne peut pas être utilisé tant que le hashCode, que l'objet peut être déplacé à tout moment par le GC (sauf si vous avez une JVM qui ne bouge jamais d'objets)

[I@106d69c
[I@52e922
[I@25154f
[I@10dea4e
[I@647e05
[I@1909752
[I@1f96302
[I@14eac69
[I@a57993
[I@1b84c92
[I@1c7c054
[I@12204a1
[I@a298b7
[I@14991ad
[I@d93b30
[I@16d3586
[I@154617c
[I@a14482
[I@140e19d
[I@17327b6

Vous pouvez voir combien de mémoire est utilisée que si vous désactivez les TLAB avec -XX:-UseTLAB https://github.com/peter-lawrey/Performance-Examples/blob/master/src/main/java/vanilla/java/memory/ArrayAllocationMain.java

public static void main(String[] args) {

    long used1 = memoryUsed();
    int[][] array = new int[200][2];

    long used2 = memoryUsed();
    int[][] array2 = new int[2][200];

    long used3 = memoryUsed();
    if (used1 == used2) {
        System.err.println("You need to turn off the TLAB with -XX:-UseTLAB");
    } else {
        System.out.printf("Space used by int[200][2] is " + (used2 - used1) + " bytes%n");
        System.out.printf("Space used by int[2][200] is " + (used3 - used2) + " bytes%n");
    }
}

public static long memoryUsed() {
    Runtime rt = Runtime.getRuntime();
    return rt.totalMemory() - rt.freeMemory();
}

imprime

Space used by int[200][2] is 5720 bytes
Space used by int[2][200] is 1656 bytes

Answer 2

Question intéressante, j'ai couru un programme simple

 int N = 100000000;
long start = System.currentTimeMillis();
int[][] a = new int[2][N];
System.out.println(System.currentTimeMillis() - start + " ms");
 

Ce qui a abouti à 160 ms . Puis j'ai couru l'autre variante

 int N = 100000000;
long start = System.currentTimeMillis();
int[][] a = new int[N][2];
System.out.println(System.currentTimeMillis() - start + " ms");
 

Ce qui a abouti à 30897 ms . La première option semble donc beaucoup mieux.

Answer 3

  int[2][veryLargeNumber] 
 

crée deux tableaux avec très peu d'éléments
tandis que

  int[veryLargeNumber][2] 
 

crée un très grand nombre de tableaux ayant deux éléments.

Remarque: la création de tableau a une surcharge. donc préféré le premier

Answer 4

En bref, int[2][veryLargeNumber] est la meilleure approche.

Celle qui est suggérée par Pierre (int[] array = new int[2 * veryLargeNumber];) est encore mieux, ou si la mémoire est de votre problème, vous pouvez utiliser aspire à la place d'entiers (long[] array = new long[veryLargeNumber];) et les opérateurs au niveau du bit, ou mieux encore, utiliser la mise en cache chaque fois que possible.

Méfiez-vous! La représentation en [I@106d69c dans la plupart des JDK/JRE distributions (Sun et Oracle) est donnée par System.identityHashCode() et il n'est pas garanti d'être unique pour chaque objet. Si vous ne pouvez pas compter sur System.out.println(array); pour vérifier l'unicité de l'objet array.