python - sirve - Elección del lenguaje de scripting para el rendimiento inicial

que es python y para que sirve (13)

"Llamado en cualquier lugar desde cada minuto hasta muchas veces por segundo. Como consecuencia, mantener su memoria y el tiempo de arranque bajo son importantes".

Esto no me suena como un guion.

Esto suena como un servidor que maneja solicitudes que llegan de cada minuto a varias veces por segundo.

Si se trata de un servidor, el manejo de las solicitudes, el tiempo de puesta en marcha no significa tanto como la capacidad de respuesta. En ese caso, Python podría funcionar bien y aún así mantener el rendimiento.

En lugar de reiniciar, solo está procesando otra solicitud. Tienes que mantener todo el estado que necesites para optimizar el rendimiento.

Tengo una pequeña aplicación liviana que se usa como parte de una solución más grande. Actualmente está escrito en C, pero estoy buscando reescribirlo usando un lenguaje de scripting multiplataforma. La solución debe ejecutarse en Windows, Linux, Solaris, AIX y HP-UX.

La aplicación C existente funciona bien, pero quiero tener una sola secuencia de comandos que pueda mantener para todas las plataformas. Al mismo tiempo, no quiero perder mucho rendimiento, pero estoy dispuesto a perder algo.

El costo de inicio del script es muy importante. Este script se puede llamar desde cualquier minuto hasta muchas veces por segundo. Como consecuencia, mantener su memoria y el tiempo de inicio bajo son importantes.

Básicamente, estoy buscando los mejores lenguajes de scripting que sean:

Plataforma cruzada
Capaz de analizar XML y Publicaciones HTTP.
Memoria baja y poco tiempo de inicio.

Las opciones posibles incluyen, pero no están limitadas a: bash / ksh + curl, Perl, Python y Ruby. ¿Qué recomendarías para este tipo de escenario?

¿Puede, por el contrario, ser un proceso de larga ejecución y responder a solicitudes http o rpc?
Esto satisfaría los requisitos de latencia en casi cualquier escenario, pero no sé si eso rompería las restricciones de la huella de memoria.

Como otros han sugerido, demonizar tu guión podría ser una buena idea; eso reduciría el tiempo de inicio a prácticamente cero. O tiene un pequeño contenedor C que se conecta a su daemon y transmite la solicitud de ida y vuelta, o tiene las solicitudes de control daemon directamente.

No está claro si esto está destinado a manejar solicitudes HTTP; De ser así, Perl tiene un buen módulo de servidor HTTP, enlaces a varios analizadores XML basados en C y soporte de cadenas extremadamente rápido. (Si no desea demonizar, tiene un buen módulo CGI con todas las funciones, si tiene control total sobre el servidor en el que se está ejecutando, también podría usar mod_perl para implementar su script como manejador de Apache.) Cuerdas de Ruby son un poco más lentos, pero hay algunas herramientas de fondo realmente buenas disponibles para ello. No estoy tan familiarizado con Python, me temo, así que no puedo hacer ninguna recomendación al respecto.

En general, sin embargo, no creo que estés tan limitado en el tiempo de inicio como crees que eres. Si realmente se llama al script varias veces por segundo, cualquier intérprete decente en cualquier sistema operativo decente se almacenará en memoria caché, al igual que el código fuente de su secuencia de comandos y sus módulos. Resultado: los tiempos de inicio no serán tan malos como podría pensar.

Dagny:~ brent$ time perl -MCGI -e0 real 0m0.610s user 0m0.036s sys 0m0.022s Dagny:~ brent$ time perl -MCGI -e0 real 0m0.026s user 0m0.020s sys 0m0.006s

(Los parámetros del intérprete de Perl cargan el módulo CGI bastante grande y luego ejecutan la línea de código ''0;'').

Cuando se escribe correctamente, C debería ser independiente de la plataforma y solo necesitaría una recompilación para esas plataformas diferentes. Puede que tenga que pasar por algunos aros #ifdef para los encabezados (no todos los sistemas usan los mismos encabezados), pero la mayoría de las llamadas normales (API no win32) son muy portátiles. Para el acceso web (que supongo que necesita a medida que menciona bash + curl), puede echar un vistazo a libcurl, está disponible para todas las plataformas que mencionó, y no debería ser tan difícil trabajar con él.

Con el tiempo de ejecución y el costo de la memoria en mente, dudo que pueda ir más rápido que C correctamente escrito con cualquier lenguaje de scripting, ya que perdería al menos algún tiempo interpretando el script ...

Debido a su requerimiento de un tiempo de inicio rápido y una frecuencia de llamadas superior a 1Hz, recomendaría quedarse con C y descubrir cómo hacerlo portátil (no siempre tan fácil como unos pocos ifdefs) o explorar la posibilidad de convertirlo en una daemon de servicio que siempre se está ejecutando. Por supuesto, esto depende de cómo

Python puede tener tiempos de inicio más bajos si compila el módulo y ejecuta el archivo .pyc, pero en general todavía se considera lento. Perl, en mi experiencia, en el más rápido de los lenguajes de scripting, así que puede que tengas buena suerte con un daemon perl.

También puedes ver frameworks multiplataforma como gtk, wxWidgets y Qt. Si bien están dirigidos a GUI, tienen tipos de datos de plataforma cruzada de bajo nivel y bibliotecas de red que podrían facilitar el trabajo de usar una aplicación rápida basada en C.

Estoy de acuerdo con Lua: es súper portátil, tiene bibliotecas XML, ya sea nativas o vinculando bibliotecas C como Expat, tiene una buena biblioteca de socket (LuaSocket) plus, para cosas complejas, algunas vinculaciones de cURL, y es bien conocida por siendo muy liviano (a menudo integrado en dispositivos con poca memoria), muy rápido (uno de los lenguajes de scripting más rápidos) y poderoso. ¡Y muy fácil de codificar!

Está codificado en Ansi C puro, y mucha gente dice que tiene una de las mejores API de C biding (llamando a las rutinas C de Lua, llamando al código Lua desde C ...).

Estoy de acuerdo con otros en que probablemente debas tratar de hacer de esta una aplicación C más portátil en lugar de trasladarla a otra cosa ya que cualquier lenguaje de scripts va a introducir una sobrecarga significativa desde la perspectiva de inicio, tendrá una memoria mucho más grande y lo hará probablemente sea mucho más lento.

En mi experiencia, Python es el más eficiente de los tres, seguido de Perl y Ruby con la diferencia entre Perl y Ruby siendo particularmente grande en ciertas áreas. Si realmente quieres intentar trasladar esto a un lenguaje de scripting, armaría un prototipo en el idioma con el que te sientas más cómodo y verifica si se ajusta a tus requisitos. Si no tiene una preferencia, comience con Python, ya que es fácil de aprender y usar, y si es demasiado lenta con Python, Perl y Ruby probablemente no puedan hacerlo mejor.

Lua es un lenguaje de scripting que cumple con sus criterios. Sin duda es el lenguaje de scripting de memoria más rápido y más bajo disponible.

Python es bueno. También verificaría el sitio web del juego de benchmarks de Computer Languages:

http://shootout.alioth.debian.org/

Puede valer la pena dedicar un poco de tiempo a comprender los puntos de referencia (incluidos los números de los tiempos de inicio y el uso de la memoria). Se comparan muchos idiomas, como Perl, Python, Lua y Ruby. También puede comparar estos idiomas con los puntos de referencia en C.

Recuerde que si elige Python, también puede extenderlo en C si el rendimiento no es bueno. Diablos, probablemente incluso podrías usar parte del código que tienes ahora. Solo recompile y envuélvalo usando pyrex .

También puede hacerlo con bastante facilidad en Ruby, y en Perl (aunque con más dificultad). Sin embargo, no me preguntes sobre las formas de hacerlo.

Si la memoria baja y el tiempo de inicio bajo son realmente importantes, es posible que desee considerar hacer el trabajo para mantener el código C multiplataforma, sin embargo, he descubierto que esto rara vez es necesario.

Personalmente, usaría Ruby o Python para este tipo de trabajo, ambos hacen que sea muy fácil hacer un código claro y comprensible que otros puedan mantener (o puedes mantenerlo luego de no mirarlo durante 6 meses). Si tienes el control para hacerlo, también te sugiero que obtengas la última versión del intérprete, ya que tanto Ruby como Python han realizado mejoras notables en cuanto al rendimiento recientemente.

Es algo personal. Programando Ruby me hace feliz, el código C no lo hace (ni bash scripting para nada que no sea trivial).

A primera vista, suena como ingeniería excesiva, como regla general, sugiero que se solucione solo cuando las cosas están rotas.

Usted tiene una aplicación que ya está funcionando. Aparentemente, desea querer llamar a la función provista desde algunas fuentes más. Parece la descripción de un servicio para mí (quizás más fácil de mantener).

Finalmente, también mencionó que esto es parte de una solución más grande, luego puede reutilizar el lenguaje, las instalaciones de las soluciones más grandes. De la descripción que proporcionó (xml + http) parece una aplicación bastante habitual que se puede escribir en cualquier lenguaje generalista (¿tal vez un contenedor web en Java?).

Algunas bibliotecas pueden ayudarlo a hacer que su código sea portátil: Boost , Qt

más detalles pueden desencadenar más ideas :)

Transfiere tu aplicación a Ruby. Si tu aplicación es demasiado lenta, perfila y reescribe esas partes en C.