whl - pyparsing python

¿Qué sigue después de pyparsing? (5)

Cambie a un analizador C / C ++ generado (utilizando ANTLR, flex / bison, etc.). Si puedes retrasar todas las reglas de acción hasta que hayas terminado de analizar, puedes crear un AST con código trivial y luego devolverlo a tu código de Python a través de algo como SWIG y procesarlo con tus reglas de acción actuales. OTOH, para que eso te dé un impulso de velocidad, el análisis tiene que ser el trabajo pesado. Si sus reglas de acción son el gran costo, entonces esto no le comprará nada a menos que escriba sus reglas de acción en C también (pero es posible que tenga que hacerlo de todos modos para evitar pagar cualquier discrepancia de impedancia que obtenga entre la Python y el código C) .

Tengo una gran gramática desarrollada para pyparsing como parte de una aplicación Python grande y pura. He alcanzado el límite de ajuste de rendimiento y estoy en el punto en que los rendimientos decrecientes me hacen comenzar a buscar en otra parte. Sí, creo que conozco la mayoría de los consejos y trucos y he perfilado mi gramática y mi aplicación al polvo.

¿Qué sigue?

Espero encontrar un analizador que me brinde la misma legibilidad, facilidad de uso (estoy usando muchas funciones avanzadas de creación de parámetros como el análisis de acciones para iniciar el procesamiento posterior de la entrada que se está analizando) y la integración con Python, pero a 10 × rendimiento

Me encanta el hecho de que la gramática es pura Python.

Todos mis bloques básicos son expresiones regulares, por lo que reutilizarlos sería bueno.

Sé que no puedo tener todo, así que estoy dispuesto a renunciar a algunas de las características que tengo hoy para obtener el rendimiento de 10 × solicitado.

¿A donde voy desde aqui?

No hay manera de saber qué tipo de beneficio obtendrá sin solo probarlo, pero está dentro del rango de posibilidades de que pueda obtener un beneficio 10x solo con el uso de Unladen Swallow si su proceso es de larga duración y repetitivo. (Además, si tiene muchas cosas que analizar y normalmente comienza un nuevo intérprete para cada una, Unladen Swallow se vuelve más rápido, hasta cierto punto, mientras más tiempo ejecute el proceso, por lo que si analiza una entrada puede no mostrar mucha ganancia, puede obtener ganancias significativas en la segunda y tercera entrada en el mismo proceso).

(Nota: saque lo último de SVN; obtendrá un rendimiento mucho mejor que el último tarball)

Parece que la gente pyparsing ha anticipado su problema. Desde https://github.com/pyparsing/pyparsing/blob/master/HowToUsePyparsing.rst :

El rendimiento de los pyparsing de pyparsing puede ser lento para gramáticas complejas y / o cadenas de entrada grandes. El paquete psyco se puede usar para mejorar la velocidad del módulo de pyparsing de pyparsing sin cambios en la gramática o la lógica del programa; las mejoras observadas han estado en el rango de 20-50%.

Sin embargo, como señaló Vangel en los comentarios a continuación, psyco es un proyecto obsoleto a partir de marzo de 2012. Su sucesor es el proyecto PyPy , que comienza desde el mismo enfoque básico de rendimiento: use un compilador de código nativo JIT en lugar de un intérprete de código de bytes. Debería poder obtener ganancias similares o mayores con PyPy si el cambio de implementaciones de Python funcionará para usted.

Si realmente eres un demonio de la velocidad, pero quieres mantener algo de la legibilidad y la sintaxis declarativa, te sugiero que eches un vistazo a ANTLR. Probablemente no el backend generador de Python; Soy escéptico si eso es lo suficientemente maduro o de alto rendimiento para sus necesidades. Estoy hablando de los bienes: el backend C que comenzó todo.

Envuelva un módulo de extensión de Python C alrededor del punto de entrada al analizador y afloje.

Dicho esto, estarás renunciando a mucho en esta transición: básicamente, cualquier Python que quieras hacer en tu analizador tendrá que hacerse a través de la API C (no del todo bonita). Además, tendrás que acostumbrarte a formas muy diferentes de hacer las cosas. ANTLR tiene sus encantos, pero no se basa en combinadores, por lo que no existe la relación fácil y fluida entre tu gramática y tu lenguaje que hay en el desarrollo de pyparsing. Además, es su propio DSL, al igual que lex / yacc, que puede presentar una curva de aprendizaje, pero debido a que está basado en LL, probablemente le resulte más fácil adaptarse a sus necesidades.

Si realmente quieres rendimiento para gramáticas grandes, no busques más que SimpleParse (que a su vez se basa en mxTextTools, una extensión C). Sin embargo, sepa ahora que tiene el costo de ser más críptico y de exigirle que esté bien versado en EBNF .

Definitivamente no es la ruta más Pythonic, y vas a tener que comenzar todo con una gramática EBNF para usar SimpleParse.

Un poco tarde para la fiesta, pero PLY (Python Lex-Yacc) , me ha servido muy bien. PLY te brinda un marco de Python puro para construir tokenizadores basados en lex y analizadores LR basados en yacc.

Seguí esta ruta cuando llegué a problemas de rendimiento con pyparsing.

Aquí hay un artículo algo viejo pero aún interesante sobre el análisis de Python que incluye puntos de referencia para ANTLR, PLY y pyparsing . PLY es aproximadamente 4 veces más rápido que realizar observaciones en esta prueba.