Depuis quelques mois, nous proposons une deuxième version de notre librairie de programmation: la librairie Typed Python. Dans un précédent article, nous avons expliqué les nouvelles fonctionnalités. Cette semaine, nous allons analyser la différence de performance entre les deux versions.
D'un point de vue technique, ces deux librairies fonctionnent complètement différemment. La librairie "traditionelle" est découpée en deux couches : une couche haut niveau implémente les objets Yoctopuce (YModules, YTemperature, etc.) et une couche bas niveau gère les communications avec le matériel.
La couche haut niveau est évidemment implémentée en Python et est supportée par tous les OS et architectures.
La couche bas niveau, appelée "yapi", fonctionne différemment. C'est une librairie dynamique écrite en C qui interagit directement avec l'OS. Cette couche n'est pas portable, et nécessite une version par plateforme supportée. Du reste, dans le sous-répertoire /Source/cdll de la librairie, vous avez toutes les versions de la couche "yapi" pour tous les OS et architectures.
Lors du premier appel à la librairie, le code Python de la couche haut niveau va détecter l'OS et l'architecture de la machine et charger la bonne version de la couche "yapi".
A contrario, la libraire Typed Python est écrite complètement en Python et est donc 100% portable. L'équivalent de la couche "yapi" est soit traité par la machine virtuelle Python ou a été réécrit en Python.
Maintenant que nous avons expliqué les différences techniques, regardons les implications que cela a sur les performances.
La taille
La taille de notre librairie peut sembler ridicule sur un ordinateur moderne, qui possède plusieurs téraoctets de stockage, mais ces deux librairies sont souvent utilisées avec des architectures beaucoup plus modestes, comme des Raspberry Pi Zero. Nous allons examiner 3 scénarios et voir la différence de taille.
Scénario 1: on inclut tout. C'est probablement le cas le plus répandu. L'utilisateur installe la librairie à l'aide de pip et tous les fichiers de la librairie est inclus.
| Python | Typed Python | |
|---|---|---|
| Fichiers Python | 1.9 Mo | 3.93 Mo |
| Fichiers binaires | 11.9 Mo | 0 Mo |
| Total | 13.8 Mo | 3.93 Mo |
Sénario 2: On inclut uniquement l'architecture utilisé. Dans ce scénario, on télécharge manuellement la librairie depuis notre site web ou GitHub et on copie uniquement la librairie "yapi" pour l'architecture courante. Pour cet exemple, on va copier uniquement le fichier libyapi-armhf.so qui est la version Linux ARM 64 bits qui est utilisé par la majorité des distributions Linux qui fonctionne sur Raspberry Pi.
| Python | Typed Python | |
|---|---|---|
| Fichiers Python | 1.9 Mo | 3.93 Mo |
| Fichiers binaires | 1.29 Mo | 0 Mo |
|
Total | 3.19 Mo | 3.93 Mo |
Sénario 3: On inclut uniquement l'architecture utilisée et uniquement la classe utilisée YRelay.
| Python | Typed Python | |
|---|---|---|
| Fichiers Python | 371 Ko | 704 Ko |
| Fichiers binaires | 1.29 Mo | 0 Mo |
|
Total | 1.70 Mo | 704 Ko |
La performance
Pour mesurer la performance de l’API, nous allons utiliser le même environnement que celui que nous utilisons depuis 2012. C'est à dire un Yocto-Relay relié à un Yocto-Knob. De cette manière, on peut détecter l'état de la sortie du relais à l'aide du Yocto-Knob.
Le programme modifie l’état du Yocto-Relay et chronomètre la différence de temps entre l’envoi de la commande et la notification de changement d’état du Yocto-Knob. Pour plus de détail sur ce programme et ce montage, vous pouvez relire l'article que nous avions fait sur le sujet.
Le programme effectue 3 mesures: la première mesure est le "set time". C'est la durée moyenne de l'appel qui commute l'état du relais.
La seconde est "set/get time". C'est-à-dire la durée moyenne d'appel pour commuter le relais et relire l'état du relais. C'est le test qui est le plus long et le moins efficace, car il travaille en polling, c'est-à-dire que l'état du complet Yocto-Relay est rechargé à chaque itération.
La dernière mesure est la durée moyenne entre la commutation du relais et l'arrivée de la notification que l'état du Yocto-Knob a changé. Ce test utilise le mécanisme de callback et est le moyen le plus efficace d'écrire du code réactif.
Pour plus de détails entre le mode polling et callback, vous pouvez relire notre article sur le sujet.
Nous avons exécuté ce programme sur un Raspberry Pi 3 avec les modules branchés directement sur les ports USB. La dernière version de VirtualHub est installée. L'application de test utilise l'URL "127.0.0.1" pour accéder aux modules en passant par VirtualHub. Note: il serait possible de se passer de VirtualHub pour la librairie traditionnelle, mais nous avons voulu comparer les deux librairies dans les mêmes conditions.
Et voilà les résultats.
| Test | Python | Typed Python (sync) | Typed Python (async) |
|---|---|---|---|
| Set | 5.47 ms | 6.44 ms | 6.44 ms |
| Set/get (polling) | 25.50 ms | 25.22 ms | 24.57 ms |
| Set/get (callback) | 8.08 ms | 13.65 ms | 12.74 ms |
Les performances de la librairie Typed Python sont légèrement inférieures, mais elle utilise moins de ressources. En effet, la librairie Typed Python n'a besoin que d'un seul thread.
Par ailleurs, si vous devez intégrer nos modules dans une application Python qui utilise les fonctionnalités async/await, la librairie Typed Python sera plus efficace et plus réactive.
Conclusion
En conclusion, la librairie Typed Python, bien que légèrement moins performante en terme de vitesse d'exécution, présente des avantages significatifs en matière de portabilité et d'efficacité des ressources. Le choix entre les deux librairies Python dépend des projets. Si la performance brute est critique, la librairie traditionnelle est plus adaptée, mais, pour les applications fonctionnant sur des machines plus limitées ou sur des architectures plus exotiques, la libraire Typed Python est plus adaptée.
