Optimisation mémoire sur des String

Bonjour à tous.

Voici mon problème:

Je travaille actuellement sur une base de données basée sur des fichiers indexés (une ligne correspond à un enregistrement, le champ 1 étant défini par les caractères 1 à X de cette ligne, le champ 2 par les caractères X+1 à Y de cette ligne, etc...)

Je dois convertir cette "base" en objets JAVA. Je lis donc mes fichiers, et je les découpe... seulement voilà, cette opération est trop gourmande en mémoire, et je suis donc en train de rechercher des axes d'optimisation.

Dans les fichiers que je lis, chaque caractère est codé sur 1 octet. Or la classe "String" utilise des "char" codés sur 2 octets.
Vu le nombre "industriel" de "String" que je génère, cette différence a de l'importance.

J'ai bien trouvé dans la FAQ cette information permettant de changer l'encodage, http://java.developpez.com/faq/java/...#charsetString mais cela ne change pas (du moins je crois... n'hésitez pas à me reprendre si j'ai tort) le fait que chaque caractère soit codé par un "char".

J'aurais donc voulu savoir (avant de redévelopper une classe qui réponde à mon besoin), si il existait une classe "LightString", basée non pas sur un char[] mais sur un byte[].

Je ne connais rien de pratique dans le JDK.

Dans Commons Primitives de jakarta / apache, tu as ArrayByteList, An ByteList backed by an array of bytes, disent-ils (sic, même si je connais mal l'anglais). Peut être c'est bon pour toi ?

Effectivement, les Strings seront toujours codés en interne sur 16 bits, quelque soit l'encodage.

Par contre, si tu fais des manipulations de chaines, n'oublie pas d'utiliser les StringBuffer, ca limite le nombre d'objets créés.

Si tu ne fais pas ou peu de manipulation de chaines, tu peux garder des references sur des tableaux de bytes.

je ne saisi pas trop ce que tu veux faire, quand tu parles de charger les données du fichier en objets java ...

c'est des données d'une base ? sous réserve que ce soit possible, n'est-il pas possible pour toi de charger ces données directement dans une bdd, HSQL par exemple. Puis ensuite de charger ces objets en jdbc ...

enfin je veux dire, t'abstraire de la lecture du fichier en le laissant faire par un mécanisme du type de SQLLoader ...

Ca change radicalement ton prog mais au moins tu pourras traiter un grand nombre de données avec moins de charges pour Java et sa mémoire ...

enfin bon, c'est une idée en passant ...

Citation:

---

Envoyé par CyberChouan

Dans les fichiers que je lis, chaque caractère est codé sur 1 octet. Or la classe "String" utilise des "char" codés sur 2 octets.
Vu le nombre "industriel" de "String" que je génère, cette différence a de l'importance.

---

L'importance est quand même limitée car il n'y a qu'un facteur multiplicatif de 2, ça n'a rien d'exponentiel.
Même si tu développe ou trouve un LightString qui prend donc deux fois moins de place, ça ne pourra pas résoudre complètement ton problème.
Il est possible que cela te permette de faire fonctionner l'appli sur le(s) exemple(s) que tu utilise actuellement, mais il suffit que ta base augmente un peu pour que tu te retrouve dans la même impasse. Et là, tu ne pourra plus réduire.

Donc je te conseille plutot de ne pas rester sur cet objectif là, seul il ne résoudra rien. Comme les autes l'ont suggéré, prête attention à la manière dont tu manipules les String. Je pense qu'une modif de l'algo (à bas ou à haut niveau) sera nettement plus utile, en parrticulier sur le long terme.

Une autre solution qui peut fonctionner dans des cas précis la fonction Sring.intern() qui renvoie une référence vers la même String d'un pool qui est maintenu en interne par la classe String

Bref si tu as beaucoup de fois la même String "toto" tu n'auras qu'un objet "toto" pour toutes tes références.
Le revers de la médaille c'est que plus tu as de String plus le pool sera grand et plus le temps de recherche dans ce pool, intrinsèquement fait par le intern(), sera long
Par contre, autre bien fait c'est que tu peux utiliser directement le == au lieu du equals() (gain de temps) car tu as toujours la même référence sur "toto"


As toi de voir si c'est utilisable dans ton cas

essaie StringBuffer