Le coût des données n'est pas celui que l'on croit...

Une des raisons de l'obésiciel est l'explosion des données. Mais quand on regarde de plus prés, cette augmentation de la taille n'est pas seulement due au nombre de données mais aussi  à une obésité des données. La raison ? Le coût caché des données.

L'obésiciel et les données

L’institut IBM TJ Watson Research Center  Hawthorne a étudié pendant 10 ans des applications écrites en langage java volumineuses et notamment leurs performances mémoire. Les constats sont que concernant l’espace mémoire Heaps (espace mémoire où sont stockées les données dynamiques), il y a une augmentation de 500 Mo à 2-3 Go ces dernières années mais pas nécessairement d'augmentation du nombre d'utilisateurs supportés ou du nombre de fonctions. Dans la plupart des cas :

  • il faut 1 Go de mémoire pour supporter quelques centaines d'utilisateurs
  • Sauver une session utilisateur nécessité 500 Ko
  • il faut 2 Mo pour un index de texte par document
  • Il y a 100 Ko de données temporaires qui sont créées par clic sur le net

Les conséquences sont néfastes selon l’institut sur la scalabilité, la consommation d'énergie et la performance.

Les bits de bourrage (padding)

La taille des données n'est pas forcément celle que l'on croit quand on développe. Les contraintes imposées par les architectures matérielles obligent les compilateurs et les environnements d'exécution à ajouter des données aux données utiles et à les réorganiser en mémoire. L'alignement et la taille d'adressage sont par exemple des contraintes « dimensionnantes ».

Les compilateurs doivent suivre les restrictions d'alignement des données définies par les microprocesseurs. Cela signifie que les compilateurs doivent ajouter des octets de bourrage (padding) entre les données définies par l'utilisateur afin que les restrictions imposées par le microprocesseur ne soient pas violée.

Voici un exemple d'une structure : 

struct {

    bool b;

    double d;

    short s;

    int i;

};

La structure va donc occuper: 1 (bool) + 7 (padding) + 8 (double) + 2 (short) + 2 (padding) + 4 (int) = 24 bytes. Alors que pour 

struct {

    double d;

    int i;

    short s;

    bool b;

};

La taille sera de 8 (double) + 4 (int) + 2 (short) + 1 (bool) + 1 (padding) = 16 bytes.

Ce surcoût de taille est encore plus important pour les architectures 64 bits. Les applications ont généralement de nombreux objets de petites tailles et des pointeurs et cela oblige à ajouter des bits de bourrage, des données supplémentaires et donc à augmenter la mémoire nécessaire.

Il est donc nécessaire de réfléchir à un placement optimisé pour les structures, plus particulièrement celles qui sont utilisée souvent et qui ont une taille importante.

En code natif mais aussi en code managé

Cette pratique ne s’applique pas uniquement aux langages natifs mais aussi aux langages managés. Mais cela va nécessiter d’utiliser des API spécifiques. En .net par exemple, on utilisera la classe Marshall pour accéder à des fonctions d’allocation non managés de la mémoire si l’on veut optimiser la déclaration des structures :

[StructLayout(LayoutKind.Sequential, Pack = 1)]

[StructLayout(LayoutKind.Explicit)] avec des champs [FieldOffset(0)] devant chaque élément soit par exemple : 

 struct Point3        

{             [FieldOffset(0)]

            public bool b;

            [FieldOffset(1)]

            public double d;

            [FieldOffset(9)]

            public bool b;

          }

Pour connaître la taille de la structure, on utilisera System.Runtime.InteropServices.Marshal.SizeOf(data). Le gain dans .net peut ainsi aller jusqu'à 30% sur la taille d'une structure.

Et Java ?

Le constat pour des langages comme Java est encore plus flagrant. Pour un double, JVM impose un overhead de 16 bytes pour 8 bytes utiles soit 67% de données non utiles. Le surcôut sur certaines collections monte ainsi jusqu'à 90%. Les marges d'optimisation sont ici larges. Mais on verra cela dans un prochain article...

Source : Livre Green Code Lab

Pour aller plus loin : Padding en fonction des plateformes et des compilateurs

Technologie: 
Catégorie: 

Ajouter un commentaire