Ingénierie des performances avec Python 3.12

Mon, 26 Dec 2022 22:54:29 +0000

3.12 apporte le profilage des performances ! Prenez une seconde pour aller consulter https://docs.python.org/3.12/howto/perf_profiling.html et en effet le changelog à https://www.python.org/downloads/release/python-3120a3/

La partie importante (pour ce post) des liens ci-dessus est :

""" Le profileur de performances Linux est un outil très puissant qui vous permet de profiler et d’obtenir des informations sur les performances de votre application. perf dispose également d’un écosystème d’outils très dynamique qui facilite l’analyse des données qu’il produit.

Le principal problème avec l’utilisation du profileur perf avec les applications Python est que perf ne permet d’obtenir des informations que sur les symboles natifs, c’est-à-dire les noms des fonctions et des procédures écrites en C. Cela signifie que les noms et les noms de fichiers des fonctions Python dans votre code n’apparaîtra pas dans la sortie de la perf.

Depuis Python 3.12, l’interpréteur peut s’exécuter dans un mode spécial qui permet aux fonctions Python d’apparaître dans la sortie du profileur de performances. Lorsque ce mode est activé, l’interpréteur interposera un petit morceau de code compilé à la volée avant l’exécution de chaque fonction Python et il apprendra à perf la relation entre ce morceau de code et la fonction Python associée à l’aide de fichiers de mappage de perf. """

écrire un “mauvais” programme

J’ai hâte d’essayer ça, alors allons-y. Tout d’abord, créons un script python à profiler. Je le fais avant d’installer Python 3.12 car je veux créer un FlameGraph de l’apparence de ce processus dans 3.10 vers 3.12. Ici, nous avons un script qui tente d’effectuer des recherches sur une grande liste :

import time


def run_dummy(numbers):
    for findme in range(100000):
        if findme in numbers:
            print("trouvé", trouvemoi)
        else:
            print("manqué", me trouver)


if __name__ == "__main__":
    # create a large sized input to show off inefficiency
    numbers = [i for i in range(20000000)]

    start_time = time.time()  # get the current time [start]
    run_dummy(numbers)  # run our inefficient method
    end_time = time.time()  # get the current time [end]

    duration = end_time - start_time  # calculate the duration
    print(f"Durée: {duration} secondes")  # print the duration

En exécutant ceci, j’obtiens le résultat suivant:

python3.10 assets/dummy/perf_py_proj/before.py
...
trouvé 99992
trouvé 99993
trouvé 99994
trouvé 99995
trouvé 99996
trouvé 99997
trouvé 99998
trouvé 99999
Durée : 36.06884431838989 secondes

36 secondes suffisent pour que nous prélevions un nombre raisonnable d’échantillons.

des flamegraphes !

Nous pouvons maintenant créer notre FlameGraph :

# enregistrer le profil dans le fichier "perf.data" (sortie par défaut)
perf record -F 99 -g -- python3.10 assets/dummy/perf_py_proj/before.py
# lire perf.data (créé ci-dessus) et afficher la sortie de trace
perf script > out.perf
# plier les échantillons de pile en une seule ligne
# ici, je fais référence à ~/FlameGraph/ - vous pouvez l'obtenir à partir de https://github.com/brendangregg/FlameGraph
~/FlameGraph/stackcollapse-perf.pl out.perf > out.folded
# générer un flamegraph
~/FlameGraph/flamegraph.pl out.folded > ./assets/perf_example_python3.10.svg

Cela nous donne un joli SVG qui visualise les traces :

Ce n’est pas utile … Je peux voir que la plupart du temps a été passé dans “new_keys_object.lto_priv.0” mais cela n’a aucun sens dans le contexte du code.

C’est l’heure de Python 3.12…

Je dois d’abord l’installer - les étapes pour cela varient selon le système d’exploitation - suivez les instructions de construction ici pour votre environnement : https://github.com/python/cpython/tree/v3.12.0a3#build-instructions

# pour moi sur ubuntu:22.04
# assurez-vous que python3-dbg est installé
sudo apt-get install python3-dbg

# construire python
export CFLAGS="-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer"
./configure --enable-optimizations
make
make test
sudo make install
unset CFLAGS

# après cela, j'ai réinitialisé le lien symbolique de mon système python3 à 3.10 car 3.12 n'est pas encore stable
# pour tester python3.12, j'appellerai "python3.12" au lieu de "python3"
ln -sf /usr/local/bin/python3.10 /usr/local/bin/python3

Avec cela installé, je dois d’abord activer le support des performances. Ceci est détaillé dans https://docs.python.org/3.12/howto/perf_profiling.html et il y a trois options : 1) une variable d’environnement, 2) une option -X ou 3) dynamiquement en utilisant sys. J’opterai pour l’approche des variables d’environnement car cela ne me dérange pas que tout soit profilé pour un petit script :

export PYTHONPERFSUPPORT=1

Maintenant, nous répétons simplement le processus ci-dessus en utilisant à la place le binaire python3.12 :

# enregistrer le profil dans le fichier "perf.data" (sortie par défaut)
perf record -F 99 -g -- python3.12 assets/dummy/perf_py_proj/before.py
# lire perf.data (créé ci-dessus) et afficher la sortie de trace
perf script > out.perf
# plier les échantillons de pile en une seule ligne
# ici, je fais référence à ~/FlameGraph/ - vous pouvez l'obtenir à partir de https://github.com/brendangregg/FlameGraph
~/FlameGraph/stackcollapse-perf.pl out.perf > out.folded
# générer un flamegraph
~/FlameGraph/flamegraph.pl out.folded > ./assets/perf_example_python3.12.before.svg

Nous allons d’abord jeter un coup d’œil au rapport avec perf report -g -i perf.data

Impressionnant! Nous pouvons voir nos noms de fonctions Python et nos noms de scripts !

Nous pouvons maintenant jeter un œil au SVG mis à jour qui visualise les traces avec Python 3.12 :

Cela semble déjà beaucoup plus utile. Nous voyons que la majorité du temps est consacrée à faire des comparaisons et dans la méthode list_contains. Nous pouvons également voir le fichier spécifique before.py et la méthode run_dummy qui l’appelle.

Temps d’enquête / le correctif

Maintenant que nous savons où se trouve le problème dans notre code, nous pouvons jeter un œil au code source dans CPython pour voir pourquoi la méthode list_contains serait si lente : https://github.com/python/cpython/blob/ 199507b81a302ea19f93593965b1e5088195a6c5/Objects/listobject.c#L440

note : vous n’aurez peut-être pas toujours accès au code source - dans de telles circonstances, vous pouvez voir le désassemblage directement dans le rapport de performance pour avoir une idée de ce qui se passe. Je vais ajouter une section rapide à la fin montrant à quoi cela ressemble

// J'ai trouvé ceci en allant sur https://github.com/python/cpython/ et en recherchant "list_contains"

static int
list_contains(PyListObject *a, PyObject *el)
{
    PyObject *item;
    Py_ssize_t i;
    int cmp;

    for (i = 0, cmp = 0 ; cmp == 0 && i < Py_SIZE(a); ++i) {
        item = PyList_GET_ITEM(a, i);
        Py_INCREF(item);
        cmp = PyObject_RichCompareBool(item, el, Py_EQ);
        Py_DECREF(item);
    }
    return cmp;
}

Nasty … en regardant ce code, je peux voir que chaque fois qu’il est invoqué, il parcourt le tableau et effectue une comparaison avec chaque élément. C’est loin d’être idéal pour notre cas d’utilisation, alors revenons au code Python que nous avons écrit. Notre Flamegraph nous montre que le problème est dans notre méthode run_dummy :

def run_dummy(nombres):
    for findme in range(100000):
        if findme in numbers: # <- c'est ce qui déclenche list_contains
            print("trouvé", trouvemoi)
        autre:
            print("manqué", me trouver)

Nous ne pouvons pas vraiment changer cette ligne car elle fait ce que nous voulons qu’elle fasse - identifier si un entier est dans numbers. Peut-être pouvons-nous changer le type de données “numbers” pour un type mieux adapté aux recherches. Dans notre code existant, nous avons :

    numbers = [i for i in range(20000000)]

    start_time = time.time()  # get the current time [start]
    run_dummy(numbers)  # run our inefficient method

Ici, nous avons utilisé un type de données LIST pour nos “nombres”, qui sous le capot (dans CPython) est implémenté sous forme de tableaux de taille dynamique et, en tant que tel, est loin d’être aussi efficace (O (N)) que les goûts d’un Hashtable pour regarder un élément (qui est O (1)). Un SET d’autre part (un autre type de données Python) est implémenté en tant que table de hachage et nous donnerait la recherche rapide que nous recherchons. Modifions le type de données dans notre code Python et voyons quel en est l’impact :

     # nous allons juste changer cette ligne, en jetant des nombres dans un ensemble avant d'exécuter run_dummy
     run_dummy(set(numbers)) # passage d'un set() pour des recherches rapides

Nous pouvons maintenant répéter les étapes ci-dessus pour générer notre nouveau flamegraph :

# enregistrer le profil dans le fichier "perf.data" (sortie par défaut)
enregistrement de performances -F 99 -g -- python3.12 assets/dummy/perf_py_proj/after.py
...
trouvé 99998
trouvé 99999
Durée : 0.8350753784179688 secondes
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.039 MB perf.data (134 samples) ]

Nous pouvons déjà voir que les choses se sont massivement améliorées. Là où auparavant cela prenait 36 secondes pour s’exécuter, cela prend maintenant 0,8 seconde ! Continuons à créer notre flamegraph pour le nouveau code amélioré :

# lire perf.data (créé ci-dessus) et afficher la sortie de trace
perf script > out.perf
# plier les échantillons de pile en une seule ligne
# ici, je fais référence à ~/FlameGraph/ - vous pouvez l'obtenir à partir de https://github.com/brendangregg/FlameGraph
~/FlameGraph/stackcollapse-perf.pl out.perf > out.folded
# générer un flamegraph
~/FlameGraph/flamegraph.pl out.folded > ./assets/perf_example_python3.12.after.svg

![python 3.12 parf flamegraph amélioré] (https://raw.githubusercontent.com/peter-mcconnell/petermcconnell.com/master/assets/perf_example_python3.12.after.svg “python 3.12 perf flamegraph amélioré”)

Il s’agit d’un Flamegraph beaucoup plus sain et notre application est maintenant beaucoup plus rapide en conséquence. La prise en charge du profilage des performances dans Python 3.12 apporte un outil extrêmement utile aux ingénieurs logiciels qui souhaitent fournir des programmes rapides et je suis ravi de voir l’impact que cela aura sur le langage.

bonus round : que faire quand on ne peut pas accéder au code source ?

Parfois, vous n’avez pas accès au code sous-jacent, ce qui peut rendre la compréhension de ce qui se passe beaucoup plus difficile. Heureusement, perf report nous permet de visualiser le code désassemblé, ce qui peut aider à brosser un tableau de ce que fait réellement la machine. C’est un premier endroit raisonnable à regarder - j’ai tendance à préférer le code source si je peux m’en procurer car cela me permet de “blâmer” / de voir les commits et PR associés. Pour l’afficher, vous pouvez procéder comme suit :

Ouvrez le rapport de perf et sélectionnez la ligne qui nous intéresse :

# cela suppose que nous avons déjà exécuté 'perf record' pour générer perf.data ...
perf report -g -i perf.data

Appuyez sur Entrée et choisissez l’option d’annotation :

Voir! Ici, nous pouvons voir à la fois le code C et les instructions de la machine. Super utile ! Vous pouvez comparer la capture d’écran ci-dessous avec l’extrait de code qui nous intéresse : https://github.com/python/cpython/blob/199507b81a302ea19f93593965b1e5088195a6c5/Objects/listobject.c#L440

chatGPT - création d'un outil de test de base de données automatisé

Thu, 08 Dec 2022 11:41:50 +0000

Création d’un outil de test de base de données automatisé avec ChatGPT

Hier soir, j’ai pensé essayer de faire en sorte que ChatGPT crée une base de données automatisée outil de test et les résultats étaient assez prometteurs.

En conclusion, avec des conseils, il a pu construire un projet à partir de zéro qui a exécuté un script python et une base de données postgres. Il a généré un schéma aléatoire et valeurs pour les tables générées aléatoirement. Il a fourni un script Python qui inspecterait la base de données et exécuterait des requêtes sur celle-ci.

Est-ce que tout a fonctionné hors de la boîte? Non. Il y a quelques bogues à corriger dans le python script qu’il a généré. Cependant, l’effort pour y remédier n’est pas élevé et certainement l’ensemble du processus de bout en bout est moins cher, en termes de temps, par rapport à partir de zéro.

J’ai trouvé que les bogues rencontrés étaient en grande partie dus à mon manque de clarté ou ordre des questions qui lui sont posées. Il était tout à fait capable de réparer lui-même erreurs / mise à jour du code existant pour correspondre aux nouvelles exigences lorsque demandé de le faire.

Le seul problème réel que j’ai rencontré était des erreurs d’API générales que l’on pourrait attendez-vous à quelque chose d’aussi populaire dans un état de prévisualisation précoce.

Je suis sorti de cette expérience en voyant ChatGPT et tout ce qui suit comme un aide au développement vraiment utile pour ceux qui savent déjà programmer. Il m’a aidé à construire un outil plus rapidement que je n’aurais pu si je me suis assis pour le faire à partir de gratter. Je ne le considère pas encore comme un remplacement pour les ingénieurs en logiciel pour deux raisons principales - premièrement : pour les applications non triviales, je soupçonne la personne l’alimentation des exigences dans le système (ou “ingénieur rapide”) doit avoir un idée raisonnable de la façon de construire un logiciel en premier lieu, afin de savoir comment pour formuler des demandes et corriger les erreurs / combler les lacunes. deuxièmement : le code étant généré n’est pas toujours solide - sans qu’un ingénieur expérimenté examine et prendre possession de tout code produit (la propriété étant importante pour raisons de maintenance) alors il y a peu de garantie que vous obtiendrez ce que vous espèrent.

Cependant; c’est encore très tôt. Les problèmes décrits peuvent-ils être résolus plus loin? Absolument. Ce type d’outillage sera-t-il “mauvais” pour les logiciels l’ingénierie dans son ensemble, à long terme ? Peut-être. Personnellement, je suis très heureux d’avoir cet outil dans mon arsenal - il m’a déjà permis d’échafauder un prototype candidatures rapidement. Est-ce que je l’utiliserais pour du code de production sur un lieu de travail ? Non plus ou moins que je ne le ferais avec des extraits de stackoverflow ou de son acabit. Pour le moment

Github repository: https://github.com/peter-mcconnell/gpt_sql_test_generator