Reprise du message précédent :
stackOverflow

oui.

Putain, le code d'URLEncoder de Sun
Les mecs créent un OutputStreamWriter pour chaque chaîne à encoder. Or, un OutputStreamWriter, par défaut le constructeur crée un tableau de 8096 bytes.
Résultat, sur 100000 chaînes à encoder, ça prend 3 secondes sur ma machine. Avec une méthode plus light qui n'utilise que du StringBuffer, c'est 200 ms On gagne un facteur 15 en temps processeur (et j'ai pas maté la conso mémoire mais ça doit être rigolo).
 
En contexte industriel, sur notre appli, on passe 5 % du temps à créer des OutputStreamWriter à la con. Et on s'étonne de se bouffer des plans perfos de la part des clients

et ton url encoding basé sur des strings tu fais comment? paske l'idée du writer c'est qu'il gere l'encodage à ta place quoi, justement...

Bin c'est juste le truc de base ; j'dis pas que je gère l'UTF-8 autres conneries du style comme un warrior, c'est juste que j'lis ma String, j'mate sir le caractère sur lequel je tombe est à encoder ou non pis vala. J'me doute qu'il y a une raison derrière l'implémentation de Sun m'enfin ça plombe nos perfos

claro

ha ben en plus si je lis bien (en vitesse), ils font quand meme plein de trucs de conversion à la main malgré leur writer...

(euh ou t'as vu que l'outputstreamwriter faisait un buffer de 8000 par defaut )

Ba en fait, j'vois pas trop à quoi sert le Writer La conversion, elle est pas dure, elle est écrite dans la javadoc (en gros, c'est %xy pour tous les caractères non alpha-numériques sauf .-_* et l'espace qui devient +). Donc y a certainement une raison à l'utilisation du Writer mais j'vois pas. Et pis dans notre appli, passer par le truc tout con avec StringBuffer suffit, donc on va pas trop chercher midi à 14h.

tout à fait

En 1.1.8, c'est vrai que j'ai pas précisé
Constructeur privé de OutputStreamWriter, il font un new byte[defaultByteBufferSize] et defaultByteBufferSize = 8192

ha bon paske ça a changé ça alors
enfin mtnt ça delegue à un truc de com.sun... donc on sait pas trop

ouaip, tout ce qui concerne les encoding a été rétrofité vers de trucs fermés, mais en unifiant au passage avec java.nio.

y'a un truc qui etait bien avec la 1.3 c'est qu'en faisant maFrame.setVisible(true) lorsque celle ci etait iconifié ca l'a faisait clignoter.
avec la 1.4 j'ai toujours pas trouvé d'equivalent

tiens c'est amusant :  
 

l'explication...

http://glenn.sanson.free.fr/killtheshadoks/s8.gif

Surtout qu'y a grosse perte de perfos Sur ma machine et pour 1 000 000 de splits sur le caractère d'espace dans la chaîne "Jouli test de split", la fonction split() prend 4 secondes et l'utilisation de StringTokenizer 930 ms
Soit un rapport de 4 en faveur de StringTokenizer...

4 fois c'est pas grand'chose, mais c'est surtout se taper 40000 compilation d'expressions régulère dans le programme ...

et tous les bugs qui vont avec

J'ai édité, mon message me semblait pas très clair
Un rapport de 4 me semble jouer dans un contexte de plusieurs milliers de traitements, quand même (sans compter la lisibilité du code et la maintenance qui va avec mais c't'une autre histoire).

qu'est-ce qui leur est passé par la tete?
jveux bien que ça soit deprécié parce que ça utilise Enumeration par exemple, mais remplacé par autre chose que les regex alors

Ba surtout que c'est connu que les regexp c'est lourd à manipuler et que ça engendre que des emmerdes pour la lecture et la maintenance Donner la possibilité de le faire, OK, l'imposer, non c'est crade

d'un autre coté ça doit etre compliqué à encapsuler pour retrouver les memes fonctionalités mais bon proute
 
sinon ton chiffre de 4x il vient d'ou?

Du test dont je parle au-dessus. J'ai fait ça :

Résultat : 930 ms pour StringTokenizer, 4230 pour split()
J'ai pas testé l'occupation mémoire.

les expressions regulieres, c'est un coup a voir de bugs "aleatoires"  

bon ben mtnt faut refaire le test en utilisant les regex correctement
(là tu recompiles 400000fois la meme regex)
 
(enfin y'a ptet un system de cache en interne comme y'avait dans oro je crois... mais jpense que y'a moyen de faire plus optimisé que ça, quand meme)

bon ben non y'a pas ou alors c'est bien caché

Ba pareil, j'fais 1 000 000 de fois new sur le StringTokenizer()

ben non c'est pas pareil, initializer un bete objet ou compiler une regex

Dans tous les cas, je cherchais à simuler l'effet sur 1 000 000 de chaînes différentes, donc ça revient à ça.
Breffe

bordel, plus j'utilise java et plus je me dis que toString est une connerie.
 
quand on fait un printOn(Writer), on oblige pas les gens à allouer quoique ce soit et on peut facilement dériver le toString() par un simple printOn(new StringWriter()).toString() alors qu'à l'inverse, un toString c'est allocation obligatoire !
 
là je suis en train de faire de l'impression d'objets et je me retrouve naturellement à faire du printOn() (à cause d'invertion de dépendances).

printOn ça vient d'ou ?

c'est pas une méthode qui est sensée être utilsée en "condition de production". C'ets plus pour du débugage ou du log rapide ...

devines ...
 
 
le smalltalk normalisé à 4 fonctions pour l'affichage des objets : printOn:, printString, displayOn: et displayString
 
la différence entre print et display, c'est que le premier est destiné au développeur (dans l'explorateur d'objet et le débuggueur) le second est destiné à l'utilisateur final (dans les interfaces graphiques, notemment).

euh nan mais en java, ça fait partie d'une interface quelconque ou bien ça vient de toi?

là je fais un printer HTML, et j'ai pas encore découplé le HTML de la logique. Donc pour l'instant, les messages abstraits vont être capables de s'imprimer en html sur un StringBuffer (oui, pire qu'un writer, mais ça sera viré plus tard au profit d'un visiteur + hiérarchie de vues).
 
 
edit : heu pour répondre à la question, ça vient de moi.

J'étais sur que ca vous ferais bondir ...
 
de tt façon y'a pas encore de flag deprecated sur le StringTokenizer et je doute qu'il y en ai un...même si c vrai que les regex permettent tout dans l'absolu, ce serait con de se se priver d'un truc simple et qui marche.
 
Edit : on devrait pas poster dans les 10min après avoir fait du code, g des String*** plein la tete

Tokenizer Mais c'est l'idée
 
 
 
Sinon, j'ai un gros souci Java Zavez déjà eu le souci sous Windows d'une JVM qui crashe en laissant un fichier hs_err_***.log sur le Desktop ? Passke c'est ce que j'ai et le coredump est aléatoire
Ca plante uniquement avec une JRE Sun 1.4 (.1 ou .2, pas de différence), avec celle de Windows 2000 ça se passe sans problème.
Apparemment, ça se produit lors de la destruction d'une applet mais d'après mes (rapides) recherches sous Gougueule, y a d'autres applis pour lesquelles ça se passe.

tout en finesse !