NSKeyedArchiver sur NSArray de grande taille au-dessus

Question

J'utilise NSKeyedArchiver dans le programme Mac OS X qui génère des données pour l'application iPhone. J'ai découvert que par défaut, les archives résultantes sont beaucoup plus grandes que prévu. Exemple:

NSMutableArray * ar = [NSMutableArray arrayWithCapacity:10];

for (int i = 0; i < 100000; i++) {
    NSString * s = [NSString stringWithFormat:@"item%06d", i];
    [ar addObject:s];
}
[NSKeyedArchiver archiveRootObject:ar toFile: @"NSKeyedArchiver.test"];

10 magasins * 100000 = 1 M octets de données utiles, mais la taille du fichier résultant est presque trois méga-octets. Les frais généraux semble être de plus en plus avec le nombre d'éléments dans le tableau. Dans ce cas, pour 1000 points, le fichier était sur le point 22k.

rapports "fichier" qu'il est un "Apple liste de propriétés binaires" (et non le format XML).

Y at-il un moyen simple d'éviter ce grand frais généraux? Je voulais utiliser la NSKeyedArchiver pour la simplicité qu'il fournit. Je peux écrire des données à mon propre, non générique, format binaire, mais ce n'est pas très élégant. En outre, l'agrégation des données en gros morceaux et l'alimentation à ces NSKeyedArchiver devrait fonctionner, mais encore une fois, qui bat un peu le point d'utilisation simple et facile et prêt à l'emploi archiveur. Suis-je manque un certain appel de méthode ou modèle d'utilisation qui réduiraient cette surcharge?

Answer 1

a déposé un bug pour suivre ce.

A part ça, NSKeyedArchiver est conçu pour l'archivage des réseaux d'objets. Comme, si un objet apparaît deux fois dans le graphique, sur désarchivage vous trouverez toujours c'est le cas. Vous voyez probablement en tête pour ce genre de uniquing.

Pour des données structurées hiérarchiques, par opposition aux réseaux d'objets arbitraires, essayez NSPropertyListSerialization. Je vois 1.8MB pour un plist binaire.