L'installation pip du module dépendant du langage C avec alpine rend l'histoire lourde
J'ai essayé de voir combien de temps cela prendrait si je pip installé docilement.
Quand je l'ai exécuté avec requirements.txt
pour l'apprentissage automatique que j'avais, le journal suivant est sorti.
Building wheels for collected packages: backcall, h5py, kiwisolver, matplotlib, numpy, pandas, pathspec, Pillow, PyYAML, pyzmq, regex, retrying, scikit-learn, scipy, tornado, typed-ast
J'ai décidé de prendre et de mesurer uniquement les modules susceptibles d'être fréquemment utilisés pendant le développement.
Il y avait deux types d'environnements que je pouvais exécuter à portée de main, donc je vais essayer les deux.
Le temps d'exécution est mesuré en ajoutant la commande time à la tête.
Dans les deux cas, ils sont exécutés dans le même fichier docker, et l'instruction RUN
contient le time pip install hoge
.
FROM python:3.8-alpine3.11
RUN apk update \
&& apk add --virtual .build --no-cache openblas-dev lapack-dev freetype-dev \
gfortran libxml2 g++ gcc zip unzip cmake make \
libpng-dev openssl-dev musl libffi-dev python3-dev libxslt-dev \
libxml2-dev jpeg-dev \
&& apk add --no-cache -X http://dl-cdn.alpinelinux.org/alpine/edge/testing hdf5-dev
RUN pip install --upgrade --no-cache-dir pip setuptools wheel && \
time pip install --no-cache-dir Cython && \
...
Comme ça.
Le tableau suivant résume la sortie des journaux lors de la construction du docker
.
.whl
tel que Cython-0.29.16-py2.py3-none-any.whl
. Il est listé ici pour comparaison avec des modules indépendants. [^ 1][^ 1]: Comme décrit dans ici, none-any
est un module dépendant de l'architecture non-OS, principalement créé avec du python pur. Ça a été. Voir aussi Official PEP425.
module / time | case1 | case2 | ||||
---|---|---|---|---|---|---|
real | user | sys | real | user | sys | |
Cython | 3.07s | 2.33s | 0.42s | 1.52s | 0.99s | 0.07s |
numpy | 5m 28.27s | 7m 6.90s | 22.11s | 2m 11.15s | 3m 23.69s | 6.05s |
pandas | 31m 46.58s | 30m 36.25s | 0m 53.83s | 14m 8.24s | 13m 53.10s | 15.88s |
Pillow | 50.81s | 44.09s | 5.99s | 24.79s | 19.88s | 1.69s |
scipy | 30m 45.99s | 36m 29.33s | 1m 45.89s | 12m 52.81s | 17m 54.87s | 42.58s |
scikit-learn | 14m 38.63s | 14m 3.37s | 28.98s | 6m 33.10s | 6m 24.84s | 10.11s |
h5py | 3m 45.58s | 3m 34.79s | 9.30s | 1m 45.87s | 1m 42.42s | 4.18s |
matplotlib | 2m 51.50s | 2m 35.53s | 13.59s | 1m 21.77s | 1m 13.70s | 6.75s |
regex | 30.52s | 28.84s | 1.24s | 13.75s | 13.06s | 0.34s |
Oups C'est bâclé, c'est bâclé
Dans le cas 1, cela prend 5 minutes pour numpy seul, et plus de 30 minutes pour les pandas / scipy. Puisque scikit-learn dépend de numpy et scipy, vous devez en fait être préparé pendant une heure. C'est plus d'une heure et demie que tout ce qui précède est combiné. Qu'est-ce que ce sera? En supposant que vous travaillez 8 heures par jour
** Vous ne pouvez déployer qu'environ 5 fois par jour **
Il devient difficile d'allouer facilement la dernière branche à l'environnement de développement et même de rechercher des corrections de bogues mineurs. Si le temps de travail est inclus, il sera encore réduit.
Pour le moment, si la mémoire est doublée, la vitesse de traitement sera également doublée, il n'est donc pas impossible de raccourcir le temps. Si vous utilisez aws, vous pouvez gagner du temps en sélectionnant un type d'instance disposant d'une grande quantité de mémoire. Cependant, dans le cas 2, qui est plus de deux fois la performance du cas 1, cela prend moins de la moitié du temps, mais cela prend environ 40 minutes au total. Vous ne pouvez déployer que 12 fois par jour.
À propos, comme «pip install» a été fait dans l'ordre à partir du haut du tableau, le temps d'exécution de certains modules inclut le temps d'exécution de l'installation des modules dépendants.
kiwisolver semble également tomber dans tar.gz
, donc matplotlib seul devrait être un peu plus rapide.
Successfully built pandas
Installing collected packages: six, python-dateutil, pytz, pandas
Successfully installed pandas-0.25.3 python-dateutil-2.8.1 pytz-2019.3 six-1.14.0
------
Successfully built scikit-learn
Installing collected packages: joblib, scikit-learn
Successfully installed joblib-0.14.1 scikit-learn-0.22.2.post1
-----
Successfully built matplotlib kiwisolver
Installing collected packages: cycler, kiwisolver, pyparsing, matplotlib
Successfully installed cycler-0.10.0 kiwisolver-1.2.0 matplotlib-3.2.1
Même s'il est léger, cela prend 1 à 2 minutes pour chacun, il est donc nécessaire de considérer l'opération qui n'a pas besoin de construire le module dépendant du langage C autant que possible. Utilisez ~~ conda, sans maintenant ~~
Au moment de «pip install», immédiatement après la fin de la conversion de roue du module, whl est redéployé et les produits nécessaires sont déplacés directement sous «site-package». C'est tout, y compris le groupe de bibliothèques partagées * .so
construit à partir de code écrit en python.
Si le binaire python3.8
est directement sous / usr / local / bin
comme alpin, il sera déplacé vers/ usr / local / lib / python3.8 / site-packages /
.
Le redéploiement peut sembler compliqué, mais il s'agit d'un déploiement de module sécurisé conforme à PEP. PEP491 le dit également [^ 2]
[^ 2]: En passant, anaconda n'est pas conforme à PEP car il utilise sa propre méthode d'installation de module. Une extrémité qui cause le danger de se mélanger.
Pour tester, «décompressez» le fichier whl pré-construit et recherchez le fichier «.so».
./numpy/linalg/lapack_lite.cpython-38-x86_64-linux-gnu.so
./numpy/linalg/_umath_linalg.cpython-38-x86_64-linux-gnu.so
./numpy/core/_operand_flag_tests.cpython-38-x86_64-linux-gnu.so
...
Si vous recherchez le chemin de la bibliothèque pour le fichier .so
après avoir installé chaque fichier whl avec pip install
, vous pouvez voir que le fichier pré-construit existe pour chaque module.
/usr/local/lib/python3.8/site-packages/numpy/linalg/lapack_lite.cpython-38-x86_64-linux-gnu.so
/usr/local/lib/python3.8/site-packages/numpy/linalg/_umath_linalg.cpython-38-x86_64-linux-gnu.so
/usr/local/lib/python3.8/site-packages/numpy/core/_operand_flag_tests.cpython-38-x86_64-linux-gnu.so
...
/usr/local/lib/python3.8/site-packages/pandas/io/sas/_sas.cpython-38-x86_64-linux-gnu.so
/usr/local/lib/python3.8/site-packages/pandas/_libs/hashtable.cpython-38-x86_64-linux-gnu.so
...
Maintenant, vous pouvez enfin importer avec python,
D'un autre côté, vous pouvez l'utiliser tant que le produit se trouve dans le chemin dans lequel python recherche le module.
Ainsi, dans Solution de contournement de l'article original, mettez plus tard des éléments autres que Python. En supposant que, je copie et colle directement sous / usr / local /
en utilisant la construction en plusieurs étapes de docker.
conda skeleton
«Cependant, il semble que conda l'ait reconstruit et introduit. Personnellement, j'ai l'impression d'être maladeRecommended Posts