Históricamente, en informática el recurso más caro ha sido el tiempo de ejecución del computador. Esto es lo que llevó al estudio de la informática que se centra en la eficiencia de diferentes algoritmos. Sin embargo, esto ya no es cierto, ya que el hardware ahora es barato. El tiempo de ejecución ya no es el recurso más caro. El recurso más caro de una empresa es ahora el tiempo de sus empleados.
|
etiquetas: python , lento , productividad , rendimiento
Larga vida a Python
- Toc, toc
- quién es?
- ...
- ...
- ...
- ...
- ...
Hola! Soy Java!
Si se trata de un software libre, lo perdono, pero en productos privativos que pagas en caja o bien por medio de la venta de datos personales... por favor, optimízamelo, que para eso pago.
Si no hay recursos, dejad de tirar el dinero en cambios que ni se os ha pedido ni son necesarios y centrad los recursos de programación en que la aplicación vaya a la velocidad que se supone que debería ir un producto con esa funcionalidad. Yo no necesito que todo se mueva según paso el ratón, si necesito que el programa no me chupe la memoria
cabroRAM o ocupe ciclos de CPU que procesador que quiero usar para otra cosa o que prefiero dejar en blanco para ahorrar energía.(pero el chiste solo vale si se compara con un lenguaje compilado, no con uno interpretado como los que han defendido aquí la mayoría)
El que escribe el artículo confunde conceptos, tú los mezclas un poco.
Python es un lenguaje de programación potente y muy útil para algunas cosas, no es un "producto educativo". Luego está ese "optimízamelo, que para eso pago": pagas por lo que te dan, y si invierten dinero en optimizarlo vas a tener que pagar más. Quizá prefieras pagar más por el uso y que vaya un poco más rápido, quizá no, eso ya es variable.
El otro día sin ir más lejos tuve que revisarme un proceso que un inútil había programado hace años que tardaba en ejecutarse casi una hora, un tiempo exageradamente largo para lo que se suponía que tenía que hacer. El susodicho proceso se revisaba unos 200K registros y para cada uno de ellos hacía una complicada búsqueda en la base de datos para ver había registros relacionados que cumplieran ciertas condiciones. La optimización consistió básicamente en identificar primero los registros que cumplían esas condiciones y en base a eso buscar los registros afectados dentro de esos 200K. Como los registros que cumplían esas condiciones eran menos de un 0,05% el proceso optimizado dura ahora apenas 1 minuto. Ni que decir tiene que el inútil que programó aquel engendro fui yo mismo. En mi defensa solo puedo argumentar que en la época en que programé aquel engendro no habia 200K registros sino como mucho una décima parte. Ale, he confesado, ya podéis lapidarme.
- Si es un código efímero que se va a usar poco, pues si, lo que se programe más rápido.
- Si es un código que se va a usar numerosas veces, conviene optimizarlo o directamente hacerlo en lenguajes más rápidos.
1. Que el código sea rápido y eficiente
2. Que el lenguaje sea potente y abstracto y permita hacer un montón de cosas chulas con poco código
¿Quieres código rapidísimo? No problem, lo que pasa es que el desarrollador va a tardar 10 veces más en escribir el código que si lo hace en python, que irá más lento pero igual lo tiene hecho en una mañana.
Al final todo depende del problema: si el rendimiento/tamaño no es crítico, es mejor un lenguaje abstracto tipo python o Java, que te permitirán tener el producto listo más deprisa y con menos esfuerzo. Si estás haciendo un juego, o algo para Arduino o algo así donde el rendimiento/tamaño sea crucial, pues lo harás en C o algo así, y te gastarás más pasta en sueldo del programador, porque va a tardar bastante más.
Y más si lo que te juegas es que la gente empiece a dejar de usar tu producto.
Pero al final la moraleja es que tienes lo que pagas, y que entre bueno, bonito y barato puedes escoger dos como máximo.
Los programadores mediocres son más baratos que los putos máquinas que son unos virtuosos, eso es un recurso más. Por eso, ante la necesidad de resolver un problema, hay que decidir cuánto nos queremos gastar, y a lo mejor nos basta con el mediocre. Porque si nos ponemos puristas y sólo buscamos la excelencia, nuestro producto va a costar 10 veces más que el de la competencia que resuelve el mismo problema (aunque tarde un segundo más), y me iré a pique.
Incluso sin un enfoque tan económico, hay que ser buen estratega, y si por hacer concesiones en rendimiento podemos añadir funcionalidades mejores, a lo mejor globalmente compensa. Pero al final es todo una cuestión de gestión de recursos, y la ingeniería el arte de hacer las cosas lo peor posible, dentro de que cumplan especificaciones
La perfección no siempre es necesaria, ni tiene sentido buscarla. Si necesito un script que lance un backup cada noche, puede tenerlo listo en 30 segundos en tres líneas de bash, o puedo dedicar una hora a escribir un programa en C++ que haga las llamadas de sistema oportunas para hacer lo mismo. Esta última opción será objetivamente más rápida y eficiente, pero esa eficiencia no me aporta nada en cuanto al resultado final, y encima he gastado unos recursos (de tiempo y dinero) que podría haber dedicado a otra cosa más necesaria. Este es un ejemplo chorra, pero puedes escalar lo mismo a cualquier situación, y resulta que al final la ingeniería es siempre lo mismo: hacer malabarismos entre eficiencia y recursos disponibles para conseguir un objetivo, sin que las decisiones que tomes impliquen necesariamente que seas un cutre por no haber buscado la perfección absoluta.
Poneros al dia: en.wikipedia.org/wiki/Julia_(programming_language)
Welcome to SAP HANA.
La optimización consistió básicamente en identificar primero los registros que cumplían esas condiciones
La solución general es programarlo de forma que se lea primero los datos a procesar y los ordene y filtre en función de lo que va a hacer. Luego los procesa.
Ordenar es primordial, pues agrupa accesos de consulta. Ni siquiera suele hacer falta programarlo si se usa una bbdd con cache.
Luego descartar los registros que se sabe que no se van a poder procesar con algún criterio. Ahí ayuda mucho disponer de metadatos (preprocesados).
Todo depende en el contexto en que estés, y de las necesidades que tengas. Siempre. La búsqueda del rendimiento y la eficiencia máxima a veces es importante, pero muchas veces no, y si nos emperramos en buscarla, por necesidad estamos dejando de lado otros aspectos que quizá en ese caso son más importantes, por lo que no estamos haciendo bien nuestro trabajo.
Al final es mercado, y se trata de ver qué prefiere el cliente: ¿un software muy muy rápido y eficiente por 10.000 eur, o uno no tan rápido pero que sólo vale 250? ¿Cuál es objetivamente mejor? Ninguno, en realidad. Depende del caso.
Larga vida a FORTRAN77!