Discussion :

[Terminator]

Bonjour à tous,

j'utilise un buffer (FileInputStream et FileOutputStream) pour charger un fichier.
Je met dans un String[] (donc un tableau de String) phrase par phrase.
Pour l'instant, avec un fichier de 50 pages, ca fonctionne, mais je voudrait savoir si il y a une limite et quelle est-elle?
Je ne sais pas à priori si c'est le stream qui prend de la place ou le String[].
Je suppose que les 2 vont dans la Ram ou je ne sais quoi? JE voudrais donc avoir des eclaircissements la dessus.

J'utilise Eclipse et donc si il y a un moyen de voir la memoire consommée en mode debeugage je suis preneur aussi.

MERCI a tous.

[hydraland]

Salut,

La limite que je vois c'est la mémoire. Je ne pense pas que tu dépasseras le nombre d'élément que peut contenir un tableau. Je sais qu'il y a des pluggins Eclipse qui permette de voir la taille mémoire mais je n'ai pas les noms en tête. Recherche sur google je ne pense pas que celà soit difficile à trouver.

A+
Hydraland

[CyberChouan]

Pour voir la mémoire globale consommée par ton appli, il suffit de mettre après le breakpoint en mode debug un appel à la méthode getUsedMem() que voilà:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
public long getFreeMem() { return Runtime.getRuntime().freeMemory(); }
public long getTotalMem() { return Runtime.getRuntime().totalMemory(); }
public long getMaxMem() { return Runtime.getRuntime().maxMemory(); }
public long getUsedMem() { return getTotalMem() - getFreeMem(); }

Par contre, tu n'obtiendras pas le détail de l'utilisation mémoire des différents objets. Cela, tu peux l'obtenir à l'aide du logiciel JProbe, qui est très efficace... mais également très coûteux!

[Terminator]

MERCI a vous deux

J'aime bien le "Tres couteux"

J'attends d'autres propositions

J'aimerais en effet regarder la memoire que mon tableau string consomme (et l'evolution de mon buffer)

[gifffftane]

À ma connaissance, les StringBuffer utilisent un tableau pour conserver leurs données. Comme un tableau se dimensionne par un entier, par construction, la taille maximum d'un StringBuffer est donc de Integer.MAX_VALUE.

Mais c'est une limite théorique... Pratiquement, j'en sais rien.

De plus, si vraiment tu t'inquiètes des relations entre buffer et mémoire, alors tu auras meilleurs compte à passer par les java.nio.Buffer. Mais il faut que le jeu en vaille la chandelle.

[iohack]

À ma connaissance, les StringBuffer utilisent un tableau pour conserver leurs données. Comme un tableau se dimensionne par un entier, par construction, la taille maximum d'un StringBuffer est donc de Integer.MAX_VALUE.

Mais c'est une limite théorique... Pratiquement, j'en sais rien.

De plus, si vraiment tu t'inquiètes des relations entre buffer et mémoire, alors tu auras meilleurs compte à passer par les java.nio.Buffer. Mais il faut que le jeu en vaille la chandelle.

Je dirais même plus : java.nio.MappedByteBuffer qui représente un buffer de byte mais qui n'est pas chargé en mémoire. Le système d'exploitation établi la liason directement entre les accès à ce buffer et le fichier physique, cela en utilisant le cache système des filesystems.
Donc classe très performante dans le cadre d'accès à des fichiers volumineux.

Cela-dit, s'il s'agit de fichiers texte, il faudra bien à un moment ou à un autre convertir les octets ( byte ) en caractères ( selon l'encodage utilisé ), et la, meilleure manière pour ne fais exploser la mémoire est de faire une lecture blocs par blocs comme avec RandomAccessFile ou FileReader.

D'ailleur, si quelqun a une astuce pour utiliser un genre de "MappedCharBuffer" ( même en utilisant l'encodage par défaut de l'OS ), je suis preneur...

[Sivrît]

La taille d'un String[] doit-être de 2*length en octets à ce qu'il me semble (plus une taille fixe par objet de l'ordre de 8o, à vérifier).

Je ne pense pas que les Stream explose la mémoire car ils doivent travailler en flux. C'est tout mettre dans des String qui va faire mal car 100Mo de texte vont prendre... 100Mo (ou pire si c'était de l'ascii). Si les fichiers deviennent trop gros pour tenir en mémoire il faudra les découper ou travailler en flux... si c'est possible.

Pour profiler sans se ruiner il y a TPTP qui est un plug-in Eclipse mais je n'en suis pas trop fan. Je viens de découvrir http://profiler.netbeans.org/ et j'adorre, surtout pour le profiling mémoire. Et le bon point est que le profileur peut s'attacher à un prog même si celui-ci est lancé depuis Eclipse

A part
ça j'ai aussi entendu du bien (mais pas encore testé) java.nio