A menudo nos dicen que las Regexps son lentas y deben evitarse siempre que sea posible.Manipulación de cadenas frente a Regexps
Sin embargo, teniendo en cuenta la sobrecarga de hacer un poco de manipulación de cadenas a uno mismo ( no estamos hablando de errores algoritmo - esto es un asunto diferente), especialmente en PHP
o Perl
(tal vez Java
) ¿cuál es la límite, en ¿En qué caso podemos considerar la manipulación de cuerdas como una mejor alternativa? ¿Qué expresiones regulares son particularmente codiciosas para la CPU?
Por ejemplo, para el siguiente, en C++
, Java
, PHP
o Perl
, ¿Qué le recomendaría
Las expresiones regulares, probablemente sería más rápido:
s/abc/def/g
o una solución basada... while((i=index("abc",$x)>=0) ...$y .= substr()...
?s/(\d)+/N/g
o un algoritmo de exploración
Pero ¿qué pasa con
- una validación de expresiones regulares de correo electrónico?
s/((0|\w)+?[xy]*[^xy]){2,7}/u/g
no habría hecho a mano y un algoritmo específico de ser más rápido (más de tiempo para escribir)?
edición
El punto de la cuestión es determinar qué tipo de expresión regular mejor sería volver a escribir específicamente para un problema dado a través de la manipulación de cadenas?
Edit2
Una aplicación común es la expresión regular Perl. Por ejemplo, en Perl, que requiere saber cómo se implementan, ¿qué tipo de regexp se debe evitar, porque la implementación hará que el proceso sea largo e ineficaz? Puede que no sea una expresión regular compleja ...
edición de julio de 2011 (basado en los comentarios)
No estoy diciendo que todas las expresiones regulares son lentos. Se sabe que algunos patrones de expresiones regulares particulares son lentos, debido a su procesamiento particular y debido a su implementación.
En las implementaciones recientes de Perl/PHP, por ejemplo, lo que se sabe que es bastante lento, ¿y debería evitarse?
Se espera la respuesta de personas que ya hicieron su propia investigación (profiler ...) y que pueden proporcionar un tipo de pautas generales sobre lo que se recomienda/evitar.
Diría que esto debería ser Community Wiki, ya que es de naturaleza subjetiva (probablemente sea más rápido, ¿qué recomendaría?). – fredley