[Py-MAD] Sobre el bloatware

[lasizoillo]

El mié., 4 mar. 2020 a las 1:09, Jesus Cea (<jcea at jcea.es>) escribió:

> La reflexión me parece perfecta y la mando aunque sea algo offtopic
> porque me parece de valor:
>
> https://tech.slashdot.org/comments.pl?sid=15887404&cid=59789568
>
>
Y python es un gran ejemplo de herramienta para hacer bloatware de forma
rápida. Algunos ejemplos que me he encontrado:

"Es tontería usar hilos por el GIL, así que hacemos todo con procesos y nos
evitamos problemas de thread safety". Un proyecto que efectivamente no era
thread safe y había crecido a 120 módulos/procesos de 60Mb cada uno (haced
el cálculo de RAM). Una máquina de 1 core normalito y 512Mb de RAM sobraba
para la versión thread-safe con hilos de todos esos módulos que seguían
creciendo en número.

"Las imágenes python de docker son demasiado grandes, migraremos a XXX
lenguaje compilado". Si, es un problema real. Python lleva un montón de
baterías incluidas, con un montón de librerías asociadas y te vas a tener
que comer el intérprete de python para ejecutar tu código; pero solo en un
layer compartido por todas tus imágenes con ese runtime de python. Otra
cuestión es que necesites 20 build dependencies en la imagen final porque
no te has molestado en separarlas de las runtime dependencies. Montar un
sistema de CI que guarde paquetes binarios en un mirror de pypi es
demasiado complejo a corto plazo, aunque luego en cada build ahorres tiempo
y espacio en disco.

"Python es lento, así que es normal que la aplicación vaya lenta". Vale,
antes con los disco rígidos daba igual si programabas en python o en
assembler, estabas esperando a los datos igual. Ahora con los discos nve un
par de órdenes de magnitud más rápidos se nota más la diferencia entre un
lenguaje rápido y lento. Pero gran parte del código python que usamos llama
a librerias en C y python es un mero lenguaje de pegamento. Muchas veces no
se hace un profiling (amo py-spy y snakeviz) para ver que evitando el
problema de queries N+1 a bbdd, metiendo un par de índices en la BBDD,
usando re.compile (o sacándolo de ese bucle donde está metido) y haciendo
un par de cambios tontos ya no hay problemas de lentitud. Otras veces hay
que rediseñar la arquitectura de la aplicación o cambiar algún algoritmo o
generar un paquete en c para algo muy simple que se usa mucho o... y
python, aun siendo más lento, deja de ser lento.

Seguro que a alguien se le ocurren otras escusas en las que se culpa a
alguna característica de python como causa erronea del bloatware generado.
Seguro que alguno más conoce más ejemplos de estos y de como evitarlos
aprendiendo un poquito más de python.

Un saludo,

Javi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.es.python.org/pipermail/madrid/attachments/20200304/780c563a/attachment.htm>