Discussion :

[plawyx]

Bonjour,

pour coder un problème, il existe le plus souvent plusieurs solutions. Existe-t-il un outil (librairie, et..) qui permet de tester l'efficacité du code (vitesse, consommation mémoire, cpu, ..) pour évaluer ces solutions ?

exemple:

pour la vitesse d'exécution, faut-il mieux utiliser StringTokenizer ou "split + regex" pour découper une "phrase" en "mot". Réponse: utilisation de cet outil ou alors la seule possibilité est d'englober le traitement dans une boucle avec par exemple, 100000 itérations.

merci

[Ceddoc]

ça dépend ce que tu veux faire, pour ton exemple tu peux déclencher un timer avant et le stopper après avoir fait une boucle de 1000 String tokenizer ou split plus regex.

Mais après tu as des outils genre Jprofiler pour analyser ce qui prend du temps dans ton appli et les fuites mémoires éventuelles

[chtig]

+1
Pour ta question, clairement éviter le split sur String, il est incroyablement lent dans le cas d'une utilisation "simple" comme celle que tu veux faire.

[plawyx]

+1
Pour ta question, clairement éviter le split sur String, il est incroyablement lent dans le cas d'une utilisation "simple" comme celle que tu veux faire.

L'exemple StringTokenizer et "split+regex" est justement qu'un exemple qui n'aborde que la vitesse de traitement.

En fait, je cherche un (ou plusieurs) outil(s) qui permet(tent) d'obtenir des mesures de vitesses, de consommation mémoires, consommation cpu et autres pour optimiser le code (ou du moins, certaines parties).

je vais regarder "jprofiler" qui comme son nom le laisse supposé, doit ressembler au profiler type langage C

merci

[Ceddoc]

http://java-source.net/open-source/profilers

[tchize_]

+1
Pour ta question, clairement éviter le split sur String, il est incroyablement lent dans le cas d'une utilisation "simple" comme celle que tu veux faire.

StringTokenizer n'est pas beaucoup plus rapide (il prend environ 80% du temps d'un String.split pour des token simples). De plus, le plus gros du travail pour split, c'est la construction du tableau. Pour cela il rajoute à une arraylist pour ensuite la convertir en array. Le Stringtokenizer ne retourne pas de tableau tout propre. Si on compare ce qui est comparable (obtention d'un array), j'arrive à 92%. Un Pattern.split deviens même plus rapide qu'un Stringtokenizer reconstruisant l'array.


Quand on optimise, il faut savoir de quoi on parle. On n'optimise pas une ligne de code juste pour le principe, c'est le meilleur moyen de tomber sur les anti pattern de early optimization.

On réalise un code raisonnable et facile à maintenir. Ensuite on utilise un profiler pour trouver et optimiser les "points chauds". Parce que franchement, entre passer 0.0019 ms sur un split ou 0.0016 ms sur un String tokenizer... Faut vraiment être critique pour se passer du confort du split

[adiGuba]

Salut,

On réalise un code raisonnable et facile à maintenir. Ensuite on utilise un profiler pour trouver et optimiser les "points chauds".

+1000



Surtout que cette affirmation vient du principe que regexp==lent, ce qui n'est pas forcément vrai !
En plus dans certains cas split() n'utilise pas de regexp sous Java 7 (et peut-être même avant mais je n'en suis pas sûr).

En effet si on utilise split() avec une chaine d'un seul caractère "simple", alors cela n'utilise pas les regexp mais un algo basé sur des indexOf(), ce qui donne chez moi un résultat 2 fois plus performant que Tokenizer (en créant aussi un tableau)...



Enfin si l'on a vraiment besoin de regexp avec split(), on peut toujours précompiler le pattern, car c'est ce qui coûte le plus cher en temps...


a++

[tchize_]

Enfin si l'on a vraiment besoin de regexp avec split(), on peut toujours précompiler le pattern, car c'est ce qui coûte le plus cher en temps...


a++

mm non, quand j'ai testé ici, la compilation du pattern comptait pour à peu près 20% du temps de split.

Mais ca dépend aussi de la taille de la chaine à couper par rapport à la taille de la pattern.

Bref: on en reviens au point de départ: mesurer le cas d'utilisation réel

[adiGuba]

En effet la taille de la chaine influence beaucoup le temps, sûrement à cause de la création du tableau !!!


Comme tu le dis, c'est le problème lorsqu'on tente d'optimiser alors qu'il n'y a pas de problème : non seulement on se complique la vie, mais on risque en plus de s'apporter des problèmes de perfs à cause de choix extrême non-adapté !



a++

[chtig]

100% d'accord avec vous sur le "faire un code propre et optimiser ensuite si besoin est".
Et au temps pour moi sur le split, j'avais zappé que ça avait été changé en Java7

Pour info, je ne disais pas ça uniquement sur le principe que regexp=lent, mais simplement pour l'avoir vécu. Dans un site de moteur de recherche, qui utilisait un moteur d'indexation qui ne savait pas gérer de clés composites, on obtenait une clé résultante qu'il fallait ensuite split sur un caractère simple pour retrouver la donnée. Lorsqu'on a fait des tests de profiling, on s'est aperçu que 30% du temps global de traitement d'une recherche utilisateur était passé à faire du split ! On a du coup codé un split à la mano tout simple, et on a gagné 30% de perfo.

[thelvin]

Pour info, je ne disais pas ça uniquement sur le principe que regexp=lent, mais simplement pour l'avoir vécu. Dans un site de moteur de recherche, qui utilisait un moteur d'indexation qui ne savait pas gérer de clés composites, on obtenait une clé résultante qu'il fallait ensuite split sur un caractère simple pour retrouver la donnée. Lorsqu'on a fait des tests de profiling, on s'est aperçu que 30% du temps global de traitement d'une recherche utilisateur était passé à faire du split ! On a du coup codé un split à la mano tout simple, et on a gagné 30% de perfo.

Pareil. Mais même si l'utilisation de regex dans split() faisait perdre un peu de temps (faut dire aussi qu'il la recompilait à chaque split() -_-°,) ce qui bouffait vraiment du temps c'est que split() ne connaît pas a priori le nombre d'éléments qu'il va renvoyer mais qu'il renvoie un tableau de pile la bonne taille. Du coup il construit une ArrayList pour mettre les éléments dedans, puis il la copie en tableau. Lourde perte de temps.
Mais cela n'est gênant que si on enchaîne les split() par millions. Si on en fait un toutes les 36 du mois c'est sans importance.
Donc, pour savoir si on est dans ce cas => profiling d'abord, optimisation ensuite.