que - PHP ereg vs. preg
preg_match php manual (5)
Me di cuenta en la biblioteca de expresiones regulares de PHP que hay una opción entre ereg y preg. ¿Cuál es la diferencia? ¿Es uno más rápido que el otro? De ser así, ¿por qué no se desaprobaba el más lento?
¿Hay alguna situación en la que es mejor usar una sobre otra?
Aunque ereg está en desuso en PHP 5.3, las funciones mb_ereg * no lo son. Creo que la razón principal de esto es porque PHP6 está reconstruyendo todo el soporte MB / Unicode y, por lo tanto, los antiguos métodos "regulares" de ereg son inútiles ya que mb_ereg será más nuevo / mejor.
Sé que no responde la pregunta sobre la velocidad, pero te permite continuar usando tanto POSIX como PCRE.
Bueno, ereg y sus funciones derivadas (ereg_match, etc.) están en desuso en php5 y se eliminan en php6, por lo que es mejor que vayas con la familia de preg.
preg es para expresiones regulares de estilo Perl, mientras que ereg es expresión regular de POSIX.
Hay mucha discusión sobre cuál es más rápido y mejor.
Si planeas algún día avanzar a PHP6, tu decisión se tomará. De otra manera:
El consenso general es que PCRE es la mejor solución para todos, pero si tiene una página específica con mucho tráfico y no necesita PHP6, puede valer la pena realizar algunas pruebas. Por ejemplo, de los comentarios del manual de PHP:
La depreciación de la expresión regular POSIX en PHP para la búsqueda de Perl es como sustituir las tablas y los ladrillos de madera por una casa con paredes y habitaciones prefabricadas. Claro, es posible que puedas mezclar y combinar algunas de las partes, pero es mucho más fácil modificarlas con todas las piezas dispuestas frente a ti.
PCRE más rápido que POSIX RE? No siempre. En un reciente proyecto de motor de búsqueda aquí en Cynergi, tuve un simple bucle con algunas funciones ereg_replace () que tardaron 3 minutos en procesar los datos. Cambié ese bucle de 10 líneas en un código de 100 líneas escrito a mano para su reemplazo y el bucle ahora tomó 10 segundos para procesar los mismos datos. Esto me abrió los ojos a lo que, en ALGUNOS CASOS, puede ser expresiones regulares muy lentas. Últimamente decidí buscar expresiones regulares compatibles con Perl (PCRE). La mayoría de las páginas afirman que PCRE es más rápido que POSIX, pero algunos afirman lo contrario. Me decidí por las marcas propias. Mis primeras pruebas confirmaron que PCRE era más rápido, pero ... los resultados eran ligeramente diferentes de los que obtenían otros, así que decidí comparar todos los casos de uso de RE que tenía en un proyecto de correo electrónico seguro (y rápido) de 8000 líneas aquí en Cynergi para verificarlo. ¿Los resultados? ¡Poco concluyente! A veces PCRE es más rápido (¡a veces por un factor mayor de 100 veces más rápido!), Pero algunas veces POSIX RE son más rápidos (por un factor de 2 veces). Todavía tengo que encontrar una regla sobre cuándo son uno más rápido. No se trata solo del tamaño de los datos de búsqueda, la cantidad de datos coincidentes o el "tiempo de compilación de RE" que se mostraría cuando repitiera la función con frecuencia: uno siempre sería más rápido que el otro. Pero no encontré un patrón aquí. Pero a decir verdad, tampoco me tomé el tiempo de analizar el código fuente y analizar el problema. Sin embargo, puedo darte algunos ejemplos. El POSIX RE ([0-9] {4}) / ([0-9] {2}) / ([0-9] {2}) [^ 0-9] + ([0-9] {2 }): ([0-9] {2}): ([0-9] {2}) es un 30% más rápido en POSIX que cuando se convierte a PCRE (incluso si usa / d y / D y coincidencias no codiciosas) ) Por otro lado, un patrón complejo PCRE similar / [0-9] {1,2} [/ t] + [a-zA-Z] {3} [/ t] + [0-9] {4} [ / t] + [0-9] {1,2}: [0-9] {1,2} (: [0-9] {1,2})? [/ t] + [+ -] [0 -9] {4} / es 2.5 veces más rápido en PCRE que en POSIX RE. Patrones de reemplazo simples como ereg_replace ("[^ a-zA-Z0-9 -] +", "", $ m); son 2 veces más rápidos en POSIX RE que PCRE. Y luego nos confundimos de nuevo porque un patrón POSIX RE como (^ | / n | / r) begin-base64 [/ t] + [0-7] {3,4} [/ t] + ...... es 2 veces más rápido que POSIX RE, pero el PCRE / ^ recibido </ t] *: [/ t] por [/ t] + ([^ / t] +) [/ t] / i insensible a mayúsculas y minúsculas es 30 veces más rápido que ¡su versión POSIX RE! En lo que se refiere a la distinción entre mayúsculas y minúsculas, hasta ahora PCRE parece ser la mejor opción. Pero encontré un comportamiento realmente extraño de ereg / eregi. En un POSIX RE muy simple (^ | / r | / n) mime-versión [/ t] : ¡Encontré eregi () tomando 3.60s (solo un número en un benchmark de prueba), mientras que el PCRE correspondiente tomó 0.16s! ¡Pero si usé ereg () (distingue entre mayúsculas y minúsculas) el tiempo de POSIX RE bajó a 0.08s! Así que investigué más. Traté de hacer que el POSIX RE no sea sensible a las mayúsculas y minúsculas. Llegué tan lejos como esto: (^ | / r | / n) [mM] [iI] [mM] [eE] -vers [iI] [oO] [nN] [/ t] *: Esta versión también tomó 0.08 s. Pero si trato de aplicar la misma regla a cualquiera de las letras ''v'', ''e'', ''r'' o ''s'' que no se cambian, el tiempo vuelve a la marca de los 3.60, y no de forma gradual, sino de forma inmediata ¡asi que! Los datos de prueba no tenían ningún "vers", otras palabras "mime" o cualquier "ion" que pudieran confundir al analizador POSIX, por lo que estoy perdido. En pocas palabras: siempre compare su PCRE / POSIX RE para encontrar el más rápido. Las pruebas se realizaron con PHP 5.1.2 en Windows, desde la línea de comandos. Pedro Freire cynergi.com
Visitar php.net/ereg muestra lo siguiente:
Advertencia
Esta función ha sido DEPURADA a partir de PHP 5.3.0 y RETIRADA a partir de PHP 6.0.0. Confiar en esta característica es altamente desaconsejado.
Baje la página un poco más y leemos esto:
Nota: preg_match (), que usa una sintaxis de expresión regular compatible con Perl, a menudo es una alternativa más rápida a ereg ().
Tenga en cuenta mi énfasis.
preg es la biblioteca Regex compatible con Perl
ereg es la biblioteca de expresiones regulares de POSIX
Tienen una sintaxis ligeramente diferente y la preg es en algunos casos ligeramente más rápida. ereg está en desuso (y se elimina en php6) por lo que no recomendaría que se use.