Discussion :

[themad]

Tout d'abord bonjour à tous !

Je suis en train de réaliser un petit programme Java qui utilise la librairie regex fournie par Java. Cependant deux problèmes se posent.

Tout d'abord je trouve l'API regex assez lente . En effet, j'utilise principalement la méthode replaceAll de la classe string (qui fait appel à l'API regex) et certains traitement prenne pas mal de temps (plusieurs milliers d'itérations/d'appels à replaceAll). Y-a-t-il une solution pour optimiser la vitesse d'execution de cette méthode ?

D'autre part un deuxième problème se pose. Lors de l'utilisation de certains motifs d'expressions regulières, j'obtiens une exception de type stackoverflowerror. Ce type d'erreur à fait l'objet de la publication d'un billet sur le site de sun : http://bugs.sun.com/bugdatabase/view...bug_id=5050507
La seule solution consiste-telle a réécrire l'expression régulière engendrant cette exception en utilisant un autre motif ?

Merci à tous. Bonne journée.

[adiGuba]

Salut,

Tout d'abord je trouve l'API regex assez lente . En effet, j'utilise principalement la méthode replaceAll de la classe string (qui fait appel à l'API regex) et certains traitement prenne pas mal de temps (plusieurs milliers d'itérations/d'appels à replaceAll). Y-a-t-il une solution pour optimiser la vitesse d'execution de cette méthode ?

Si le pattern est toujours le même, il y a une optimisation à faire qui consiste à le créer une fois pour toutes, par exemple si tu as quelque chose comme ceci :

Code :

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

1
2
3
for (...) {
    String result = line.replaceAll("regex", "remplacement");
}

Tu pourrais faire ceci :

Code :

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

1
2
3
4
Pattern pattern = Pattern.compile("regex");
for (...) {
    String result =pattern.matcher(line).replaceAll("remplacement");
}

Cela évitera de recompiler plusieurs fois le pattern, ce qui est assez coûteux...

D'autre part un deuxième problème se pose. Lors de l'utilisation de certains motifs d'expressions regulières, j'obtiens une exception de type stackoverflowerror. Ce type d'erreur à fait l'objet de la publication d'un billet sur le site de sun : http://bugs.sun.com/bugdatabase/view...bug_id=5050507
La seule solution consiste-telle a réécrire l'expression régulière engendrant cette exception en utilisant un autre motif ?

C'est inhérent aux expressions régulières elles-mêmes (et non pas à leur implémentation Java).
Il y a des expressions qui dans certaines conditions peuvent provoquer un grand nombre de récursion, ce qui provoque une grosse consommation CPU et même des stackoverflow...


Il faudrait que tu postes tes regexp et leurs objetifs...

a++

[themad]

re merci de tes réponses !

Si le pattern est toujours le même, il y a une optimisation à faire qui consiste à le créer une fois pour toutes, par exemple si tu as quelque chose comme ceci :

Entendu, je vais essayer cette piste et voir la différence .

Il faudrait que tu postes tes regexp et leurs objetifs...

Pour les regex ca ressemble à des trucs de ce genre permettant de matcher des commentaires :
- /\*[\u0000-\uffff]*?\*/ -> commentaire java /*...*/
- //.* -> commentaire java //...
- ...

Merci de ton aide .Voilà.

[tchize_]

pour l'erreur. Je me souviens avoir eu ce genre de problème avec un java 1.4, çà a été résolu avec une version de java supérieure dont l'implémentation était visiblement différente. Sans jamais savoir pourquoi çà foirait! Tout ce que j'en ai conclu à l'époque c'est que la regexp était peu en cause, c'était surtout la longueur de la string sur laquelle on faisait le match qui impliquait une énorme récursivité.

par contre le [\u0000-\uffff] çà fait un très grand range et çà inclue la séquence */, tu risque de ne pas choper la fin de commentaire puisque les regexp sont d'algorithme gourmand par défaut.

[adiGuba]

par contre le [\u0000-\uffff] çà fait un très grand range et çà inclue la séquence */, tu risque de ne pas choper la fin de commentaire puisque les regexp sont d'algorithme gourmand par défaut.

Pour cela c'est bon il utilise un quantifier "reluctant" (le *?).
Par contre quel intérêt d'utiliser [\u0000-\uffff] là où le point ferait l'affaire :

Code :

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

String pattern = "/\\*.*?\\*/";

a++

[tchize_]

Pour cela c'est bon il utilise un quantifier "reluctant" (le *?).

Honte à moi de ne pas l'avoir vu!

[themad]

bonsoir à tous !

Premier point en ce qui concerne la compilation des pattern. Effectivement, le fait de ne pas recompiler le pattern à chaque fois améliore la vitesse d'exécution du programme . Je ne saurais vous dire le pourcentage/ratio d'augmentation mais c'est visible sans faire de calcul donc ça doit quand même être non négligeable.
Seul bémol certains traitement reste encore long (et pourtant j'utilise des threads séparés...).

pour l'erreur. Je me souviens avoir eu ce genre de problème avec un java 1.4, çà a été résolu avec une version de java supérieure dont l'implémentation était visiblement différente. Sans jamais savoir pourquoi çà foirait! Tout ce que j'en ai conclu à l'époque c'est que la regexp était peu en cause, c'était surtout la longueur de la string sur laquelle on faisait le match qui impliquait une énorme récursivité.

J'utilise la 1.5 en ce qui me concerne et j'ai quand même des erreurs mais comme il l'a été dit plus haut je pense que ca vient de la regex en elle même car ca ne m'arrive que sur certains type de regex du type (x|y)*
Mais il est vrai que les regex sur lequelles j'ai travaillé au départ avait une taille assez conséquente (de l'ordre de 20 caracteres) donc peut etre la taille a-t-elle aussi une influence.

par contre le [\u0000-\uffff] çà fait un très grand range et çà inclue la séquence */, tu risque de ne pas choper la fin de commentaire puisque les regexp sont d'algorithme gourmand par défaut.

J'ai du mal a voir ce que tu veux dire par "tu risque de ne pas choper la fin de commentaire" et le rapport avec le range ? Pourrais-tu préciser s'il te plait ?

Pour cela c'est bon il utilise un quantifier "reluctant" (le *?).
Par contre quel intérêt d'utiliser [\u0000-\uffff] là où le point ferait l'affaire :

C'est noté, je changerai. En fait j'ai tenté de simplifié au maximum l'écriture de la regex en pensant que ca irait plus vite mais effectivement peut etre que le fait de mettre un "interval" large empire plus les choses que ca ne les améliore. Je vais tester la vitesse d'execution avec ta proposition de regex .

[tchize_]

je crois que la taille de la regexp a moins d'importance que la "vitesse" à laquelle elle parcours ta string pour faire le match, puisque à chaque fois qu'elle s'arrete pour un morceau trouvé et vérifie si le morceau suivant cadre avec, elle récurse (il me semble). Donc les opérateur reluctant ont tendance à augmenter la complexité. En même temps, je connais pas les détails de l'algorithme.