Otro mensaje de Salva, reenviado.
-------- Mensaje reenviado --------
________________________________ From: JJ Merelo <[email protected]> To: Lista de correo de Madrid Perl Mongers <[email protected]> Sent: Thursday, December 4, 2014 8:11 AM Subject: Re: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad de textos de la web
Bueno, en expresiones regulares al menos lo es.
Depende. Las expresiones regulares son un mundo en si mismo. Algunas cosas en Perl son muy rápidas, otras no tanto. El motor de Perl en teoría usa algoritmos que dejan mucho que desear (para poder dar ciertas funcionalidades), y es posible escribir expresiones regulares que resultan en programas con complejidad NP. Afortunadamente, en la practica lo que se usan son expresiones regulares sencillas que hacen poco uso del backtracking y por eso el rendimiento suele ser muy bueno, porque la implementación si esta micro-optimizado al límite. Tambien, desde hace algunas versiones, es posible usar en Perl motores de expresiones regulares alternativos. Por otro lado esta el caso de Java que viene con su propia librería de expresiones regulares, similar a la de Perl, y que tendrá su rendimiento. Pero además de la que viene por defecto, en Java hay muchas más librerías. Algunas escritas en C que son cuando menos tan rápidas como la de Perl, otras que usan motores determinitas con complejidad lineal garantizada, etc. Al final de lo que se trata es de que A no es mejor que B, si no que en algunos casos A es mucho mejor, en otros es B y en otros hay un C que les da mil vueltas a ambos.
En proceso de cadenas, depende.
Nope, nope. En Java, si sabes como hacerlo, el proceso de cadenas es más rápido que en Perl. El problema es que es fácil (y más cómodo) hacerlo mal.
Y en el resto, "your mileage may vary". Aquí, por ejemplo http://scholar.google.com/citations?view_op=view_citation&hl=es&user=gFxqc64AAAAJ&cstart=20&citation_for_view=gFxqc64AAAAJ:LI9QrySNdTsC la velocidad de Perl era, si mal no recuerdo, del orden de magnitud de la de una librería equivalente en Java, pero no la alcanzaba. De hecho, el autor de la otra librería cambió dos o tres cosas en la JVM y me dio un felpón.
En el fondo esto del rendimiento es una cuestión de concepto: si tu coges a dos tíos que sean unos máquinas en temas de rendimiento en Perl y en Java respectivamente y los pones a resolver el problema, en general y salvo que sea algo muy especifico que en Perl se pueda resolver llamando a un par de built-ins, lo normal es que la solución en Java sea al menos un orden de magnitud más rápida que la de Perl. Luego esta la otra forma de evaluar el rendimiento: si tu pones a dos tíos con un conocimiento intermedio de Perl y Java, a resolver el mismo problema, entonces lo que obtengas probablemente si sea el "your mileage may vary". Es lo que comentaba en el correo anterior, Perl es un lenguaje de más alto nivel y te da un conjunto de estructuras de datos (como las cadenas y los arrays) y unos algoritmos que operan sobre ellos de manera optima y rápida al estar implementados en C. En Java en cambio, lo que tienes son unas primitivas de bajo nivel y encima de ellas tu puedes implementar los algoritmos que quieras, es responsabilidad del programador que sean los óptimos. También es cierto que en algunos casos, como cuando se usan Strings Java parece que te invita a utilizar los no-optimos. _______________________________________________ Madrid-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/madrid-pm _______________________________________________ Madrid-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/madrid-pm
