lorsque les expressions régulières utilisées sont de vraies expressions régulières il existe une implémentation beaucoup plus efficace que celle de Perl
Oui, du moins si d'autres conditions sont remplies. Par exemple, sa façon d'évacuer le problème d'Unicode est une plaisanterie.
Cela permettrait donc d'accélérer grandement le traitement des expressions régulière dans de nombreux cas sans ralentir les cas où on a vraiment besoin de l'implémentation actuelle.
Ça, c'est beaucoup moins sûr. Pour que cette solution ait un intérêt, il faudrait être sûr que la construction de l'automate ne coute pas plus cher que l'exécution du code actuel. Or, tout comme il existe des cas limites pour la méthode utilisée par Perl, il existe des cas limites pour les automates, avec la différence que l'explosion ne concerne pas seulement le temps d'exécution (facile à contrôler avec un chien de garde), mais une combinaison de temps et de mémoire, et, selon le type d'automate, à la construction et/ou à l'exécution. Voilà qui devient amusant à surveiller...
Par exemple, classiquement, les grosses répétitions et les grandes classes de caractères posent problème. Est-il vraiment une bonne idée d'avoir une implémentation pour ga?bu et une autre pour \w{2,3000}ga?bu : c'est douteux, surtout s'il faut entrer dans le cas pathologique pour s'apercevoir qu'on aurait mieux fait de ne pas y aller. Mais tout ça, et bien plus, est couvert dans la discussion ci-dessus.
[^] # Re: Perl et la complexité
Posté par ɹǝıʌıʃO . En réponse à la dépêche Le colonel Moutarde, sur la table (de hachage), avec un livre de maths. Évalué à 3.
Oui, du moins si d'autres conditions sont remplies. Par exemple, sa façon d'évacuer le problème d'Unicode est une plaisanterie.
Ça, c'est beaucoup moins sûr. Pour que cette solution ait un intérêt, il faudrait être sûr que la construction de l'automate ne coute pas plus cher que l'exécution du code actuel. Or, tout comme il existe des cas limites pour la méthode utilisée par Perl, il existe des cas limites pour les automates, avec la différence que l'explosion ne concerne pas seulement le temps d'exécution (facile à contrôler avec un chien de garde), mais une combinaison de temps et de mémoire, et, selon le type d'automate, à la construction et/ou à l'exécution. Voilà qui devient amusant à surveiller...
Par exemple, classiquement, les grosses répétitions et les grandes classes de caractères posent problème. Est-il vraiment une bonne idée d'avoir une implémentation pour ga?bu et une autre pour \w{2,3000}ga?bu : c'est douteux, surtout s'il faut entrer dans le cas pathologique pour s'apercevoir qu'on aurait mieux fait de ne pas y aller. Mais tout ça, et bien plus, est couvert dans la discussion ci-dessus.