Voila j'ai un JTextArea remplit d'un certain text, il faut que je balaye le JTextArea char par char et remplacer les char par une autre chaine et écrire cette nouvelle chaine dans un autre JTextArea. je fait le tout dans un Thread pour pouvoir moniter l'avancement sur un JProgressBar
 
J'ai testé deux méthodes, je li le char, je cherche le correspondant et je le append dans le JTextArea resultat > ca plante et ca ram , deuxieme méthode je cré une String énorme et je fait un setText a la fin > c'est lent mais ca plante plus
 
je cherche a optimisé merci de donner vos avis    
 
 
 
voici en gros ce que je fait pour l'instant :
 

StringBuffer

 
effectivement j'aurai du y penser plus tot merci
 
mais now le pb c'est pour afficher un Stringbuffer dans un JTextArea, si je fait un toString setText ca revient au meme

concrètement tu fais quoi?

 
Je code un text en binaire, c'est a dire j'ai ma table de convertion je prend un "a" et je le transforme en "001" (par exemple) et le truc c'est que ca doit etre graphique, donc on doit voir dans un JTextArea une suite de 1 et de 0 correspondant au codage du text d'un autre JTextArea, donc ca fait bcp de  1 et de 0 a afficher je cherche donc un moyen maintenant d'afficher mon StringBuffer sans tout faire ramer ...

aucun, faut repasser par la casse String

 
       
 
 
faut que je trouve le moyen de d'afficher bcp de 0 et de 1 dans un composant sans tout faire ramaÿ    
 
tu penses vraiment qu'il ya pas de solution ?
 
paske le .setText(stringbuffer.toString()) c'est bof

ça rame à ce point ? quel volume le texte source ?
 
 
edit : tu ferais peut etre bien de tout lire d'un coup, créer le StringBuffer avec la bonne taille initiale d'une part, et pour ta fonction char -> binaire, tu peux soit l'améliorer (avec un String bin[256] pour pas faire 8 tests à chaque fois) ou bien l'inliner à la main pour voir. sinon, je vois rien d'autre : si tu dois traduire tout un texte en un autre, c'est la seule manière il me semble

déjà, utiliser StringBuffer.append() à la place de Strign.concat() ca te fera bcp gagner.
 
ensuite l'autre idée, si tu veux éviter de créer des String inutiles c'est que plutot que ta chaine de codage retourne une String, elle ajoute la chaine à retourner dans un StringBuffer. ex :
String enorme = "";
enorme = enorme.concat(renvoie_chaine((char)c));
devient
StringBuffer enorme = new StringBuffer();
ajoute_chaine((char) c, enorme);
 
à suivre l'arrivée d'un prochain SringBuilder en jdk1.5 (un StringBuffer non synchronizé d'après ce que j'ai compris)

euh sur un StringBuffer tu peux faire append(char c) hein ...
 
et pour StringBuilder, j'ai envie de resortir le lien qui explique le fait que la synchronization diminue les perfs est une legende urbaine

 
ben en fait ca rame pas au niveau du calcul et de la création du StringBuffer, ca ca marche tres bien, mais quand je veu l'afficher en repassant par un String j'ai un beau "java.lang.OutOfMemoryError" , sur un test d'uun fichier d'un mo.
 
j'ai pas bien comprit ton histoire de String bin[256]  

 
oui avec le stringbuffer ca marche tres bien, j'append a chaque passage et c'est tres rapide, maintenant le probleme se pose pour l'affichage car je doit repasser par un string et donc on revient au pb de départ

 
c'est que tu fais péter la limite des 64Mo si je ne m'abuse
essaye
-Xmx96m
 
tu ferais bien de profiler tout ça quand même pour être sur de savoir ou sont les problèmes. elle fais quelle taille ta String finale ? moi je te conseille de tout lire d'un coup déjà, à savoir n char, ensuite new StringBuffer(n), remplissage [appel au gc], toString
 

 
ben
 
String bin[256]={
 "00000000"
 "00000001"
 ....
 "11111111"}
 
passe en hexa  

 
je comprend pas tout   , bref le principe de base c'est de simuler la compression d'un fichier text, c'est a dire ouvrir le fichier dans un jtextarea, ensuite calculer le code correspondant a chaque char ( les trucs de bases de compressions, on calcul les effectifs ) donc en fait mon code obtenu est un code a longeur variable, et il est préfix pour que je puisse décoder.
 
le principe c'est donc ouvrir un fichier(jtextarea) > trouver le code > afficher le fichier codé en binaire (jtextarea) > décoder > afficher le text identique a l'original.
 
le probleme vient bien quand je fait le tostring de mon sb, car j'ai un jprogressbar qui monitore, et en fait a 100% ca commence a ramer... et out of mémory, sur des petits fichiers ca marche tres bien, mais des que le fichier est un peu gros, le calul du sb marche toujours bien mais au toString ca merde
 
 
edit : un screenshot pr mieu visualiser : http://membres.lycos.fr/pok3s/jcode.jpg

mais non le problème est pas le même !!!!
Une fois que ton StringBuffer est rempli, tu le passes en String et c'est bon.
 
Le problème avec ton ancienne manip c'est qu'à chaque fois que tu faisait un concat,  ca créé une nouvelle String => si ta boucle c'était sur un fihcier d'1Mi, tu crées une String de ., 6, 9, 12, ..., 2 999 997, 3 000 000 octet. Bref, tu faisais exploser la mémoire : ton prog consommais 4,5 Téra octets de mémoire !!!! tu métonnes qu'il faisait un OutofMemory !
 
Le truc à faire : créer un StringBuffer de la bonne taille (tu peux l'estimer sir tu connais la taille du fichier). Ca évitera les copies inutiles pour l'agrandir. A la fin tu auras un StringBufferqui prendra environ 3Mo. tu fais un toString pour le récupérer sous forme de String => ca créé un 2e objet de 3Mo. C'est gourmand en rame mais on reste dans les limites du raisonable.
 
Par contre, quand tu vas voiloir afficher ca (le mettre dans ton JTextField), Swing y risque de pas être content : afficher 6 millions de caractère, il risque d'avoir du mal à digérer
 
Mais bon, c'est pas le passage du StringBuffer à String qui va poser problème

cela dit pour ta compression en elle meme, j'espere que tu travailles pas avec des char mais bien avec des byte et des opéations binaires

sans blague
 
mais ca évite de créer des chaines inutiles de directement l'ajouter au StringBuffer
 

 
ben tiens ... et la gestion des sections critiques, etc ... faut bien qu'elle les execute quand même la JVM
Dire que c'est pas aussi gourmand que la "légende" le raconte OK, mais y a forcément un coût
 
Dans le cas d'utilisation poussée du StringBuffer en monothreadé, ils prévoient une amélioration de 20% des perfs avec le StringBuilder ...

méga +1  

 
bah j'essaie mais pour opéations binaires j'ai du mal
 
edit : on gagne vraiment ?

un ton avis ?
utiliser 1 bit à la place de 8 ca risque d'améliorer les perfs ?

 
effectivment  

 
ouais mais avec des bytes je pert de la présition pour les char spéciaux ? y me reconnai pas tout en byte

ben non. tes données son sous une forme données (char[], String, etc), toi tu convertis tout ça en byte et bosse dessus), ou alors lecture directe sous forme de byte

 
heu mais par exemple un 'é' jeu pas le coder avec un byte

 
 
 
explain to me  
 
ben je sais avec un byte je peu coder que la table ascii et ca reste limité quand meme ... ou bien j'ai vraiment rien capté  

 
allé un peut de compassion  

bah regarde java.lang.Byte quand même

sinon affiche de l'hexa et ton problème de perf va s'arranger, et ça n'en sera que plus lisible

 
j'ai regardé, et je lit un peu les trucs de codages de la doc java,
 
mais en fait vous me conseillé au lieu de travailler avec un "char" pour un caratere de travailler avec un "byte" par caracter c'est ca ?
 
j'ai bien comprit que le but est d'évité de travailler avec des char codé sur 1octet, mais je comprend pas bien comment faire

ben les bytes, c'est fait pour représenter du binaire

 
je comprend pas bien comment coder un char dans un byte

j'abandonne

 
naaaaaaaaaan  

hann, je viens de réveillé, croyait que vous étiez entrain de me parler pour l'affichage, rololo 30min que je me prend la tete a essayé de comprendre ce que vous voulez lol, évidement que mon fichier compressé je l'écrit en binaire, c'est pas une fichier texte avec des 0 et des 1 dedans, c'est bien ce ca ques vous aviez peur non ?, là je bosse avec des char etc car tout doit etre graphic, mais le fichier en lui meme est évidement écrit en binaire

et donc pout mettre un gros StringBuffer avec un composant swing quelqu'un a une id ?

ben oui, pourquoi tu dis "mais" !?
dans ton example de code, tu passais justement par une methode intermediaie pour ajouter le char...
 
bref...
 

 
 
bref ... comment j'afficher mon gros StringBefouz  

je pense que t'as pas capté : le char il le transforme en String => si tu ajoute directement les différent char de la String dans le buffer c'est plus rapide que de créer une String puis de l'ajouter dans le buffer.

à quoi ca va te servir d'avoir un textfield avec des millions de caractères dedans ? c'est illisble !!  
c'est quoi l'intéret d'afficher ca ?