Et je ne sais pas pourquoi, mais ça m'a plutôt marqué.

Tellement, que dans mes premiers scripts pour le boulot, je commençais le script avec un commentaire "# You Write Stories" pour me rappeler.

 Extrait de code que j'ai retrouvé dans mes archives

Avec the rise of AI, on prompt ce qu'on veut voir comme résultat, mais on choisit plus vraiment le chemin. C'est comme demander à un chauffeur de nous emmener d'un point A à un point B, mais par contre on a aucune idée de comment on va s'y rendre, ni dans quel état on va arriver, on sait juste qu'on arrivera.

Je ne vais pas m'éterniser sur les sujets de la AI fatigue, sur le fait que finalement on passe des dizaines de fois plus de temps à review du code plutôt qu'à raisonner et l'écrire, se l'approprier, de la perte de sens ...

Mais finalement, est-ce que c'est worth d'apprendre tous ces concepts si l'IA peut tout faire pour nous ?

L'art vs le code

Après réflexion, l'IA pour le code, c'est un peu comme l'IA pour le design. Ça peut faire le taff, mais t'as un million de manières de faire pour arriver à un résultat.

Puis, même si les images faites par IA sont stylées et que ça se fait en deux secondes. Ça ne sera jamais aussi original que si c'était fait par un humain, et puis, une image générée par IA ça se voit, et ça montre vite ses limites. Si tu veux un truc HYPER spécifique, t'es pas sorti de l'auberge.

Les personnes qui savent à peu prés comment fonctionne un LLM savent que par définition, c'est pas fait pour être original. Ils sont codés pour te donner la réponse la plus probable en fonction du contexte qu'ils possèdent.

Et si le code c'était pareil ? Lorsqu'on prompt, on dit ce qu'on veut faire, parfois on guide en donnant une direction. Par exemple, quel langage, quel framework, quelles libs, l'architecture globale.

Mais si on voulait vraiment, on pourrait prendre la casquette d'artiste, et faire un truc qui sort des sentiers battus.

Disclaimer:

(bon, des fois c'est bien de rester classique, on va pas se mentir, si c'est pour devenir le Van Gogh du code et se couper l'oreille, c'est pas trop worth)

Donc à tous ceux qui se demandent si ça sert toujours d'apprendre à coder, apprendre les concepts etc.. Je dirais oui, car finalement, l'IA répond à la question qu'on lui pose, genre "réalise ceci".

Mais le COMMENT, c'est à vous, l'artiste, de décider comment. Vous faites votre propre palette de couleurs, et vous créez.

Un exemple basique

Si demain j'voulais réaliser une web app qui va récupérer des flux RSS sur des blogs et me les afficher, j'pourrai le faire comme ceci. Ça fonctionne, c'est simple. Mais, on pourrait faire de pleins de manières différentes.
 Version simpliste d'un news feed system design

On pourrait décider d'ajouter de nouveaux components, pour avoir une architecture plus robuste ou de meilleure performances.
 Version plus robuste mais plus compliquée

Ou on pourrait tout simplement faire un truc abominable, mais qui marcherait et qui demanderait beaucoup moins de setup.
 Don't do this plz

Les images dessus ont été réalisées grâce à mon tool https://polydraw.io . C'est un fork de Excalidraw avec des features en plus, des shortcuts sympas et une autre vibe.

Le bonus

Il y a tellement de gens qui perdent du sens, qui vont arrêter d'apprendre, les gens vont s'en remettre de plus en plus à l'IA. Ils vont perdre en patience, résilience et gestion de la frustration et en connaissance. Toutes ces qualités essentielles pour un dev'.

Ils vont devenir rouillés.

Finalement, je pense que d'ici quelques temps, un bon niveau d'il y a quelques années sera un très bon niveau demain. Parce que la barre aura baissé.

C'est mon opinion, I guess we'll see.

Bref, c'était un p'tit exercice d'écriture aussi, ça faisait un p'tit moment que je ne l'avais pas fait. J'ai d'autres sujets, plus techniques sur lesquels je voudrais bien écrire, mais il me reste à trouver le bon format / média.

See you!

We'll be running profiling on the same code with different tools so you can see the output generated. At the end of this article we'll make a comparison of the tools. And when to use which one.

The tools

• PyInstrument : Statistical profiler, great for getting a high-level overview of what your code is doing.

• cProfile : Deterministic profiler, useful for getting a detailed breakdown of every function call.

• Py-Spy : Sampling profiler that can attach to running processes , great for production debugging.

• Scalene : A powerful profiler that tracks CPU time, wall time, and memory.

• time(Linux shell) : Simple but effective for measuring total runtime, including imports, I/O, and startup overhead.

The code we'll profile

Day 2 of Advent of Code 2024 (yeah, shame on me, I only did Day 1 last year, so I did the second day for this example...)

I've implemented a solution to the second part of the challenge (usually the trickier one).

To better highlight potential optimizations (and make profiling results more meaningful), I've deliberately increased the input size, so we can observe where time or memory is being consumed.

Here's what I came up with, it could be improved (that's the point) but it works.

time

time python aoc2-2.py

The classic time command gives us a quick look at how long the entire script took to execute. In this example, the total runtime is reported as 2.850 seconds , with almost all of it spent in user space (2.81s user) and very little in system calls. This tool is extremely simple but useful to establish a performance baseline. However, it gives us no insight into what inside the program took time, just that it took time.

PyInstrument:

pyinstrument -r html aoc2-2.py

PyInstrument offers a view of where your code spent its time , using stack sampling. In the screenshot, we can see that most of the time is spent inside the main function, and more precisely inside a generator expression and the check_is_safe function. PyInstrument makes it easy to spot where time accumulates.

Also, the interface is clear and beautiful.

cProfile

python -m cProfile aoc2-2.py -s cumtime

With cProfile, we get a detailed view of function calls, how many times each was called, the total time spent, and how it contributes to cumulative runtime. In this case, check_is_safe was called over 5 million times, and sorted and abs were also heavily used. This profiler is very precise.

Still, it's great for seeing exact function-level cost and how often they're triggered.

I personally like to start with PyInstrument to get a rough idea and then use cProfile. Since it's a deterministic profiler, the overhead is superior to tools like PyInstrument.

Did you learn something ? Subscribe for free to receive new posts.

py-spy

sudo py-spy record -o profile.svg -- python aoc2-2.py

Py-Spy generates a flame graph , which visualizes stack traces over time. In this case, we see a wide block for <module> and main, then narrower blocks representing the generator expression and check_is_safe. This tool is great for profiling production code or long-running scripts without modifying source code or restarting processes. It gives a quick visual cue about where time is spent, though not as detailed as line-level profilers.

I like this tool, but I only use it when I need to debug something that is already running and I cannot restart or reproduce locally. It also could be used to see where a program is stuck. It has very low overhead, and run in a separate process, so it should not impact your production code.

Scalene

scalene aoc2-2.py

Scalene combines CPU profiling, memory tracking, and even line-level timing into one HTML report. In the screenshot, we see that the check_is_safe function is a hotspot, and memory usage spikes within that block. It even highlights how much time is spent on each line. This tool is ideal when you want to understand not just how long things take, but also how much memory they consume, line by line.

What would TK do ? My workflow.

• Start with time if your script is easy to run and you just want a quick sense of how long it takes overall.

  
  

• Then use PyInstrument to get a high-level overview of where the bottlenecks are. It's fast, has low overhead, and gives a clear call-stack timeline. It has amazing integrations with web frameworks and all kind of things you can run into.

• If you want to dig deeper and optimize specific functions , reach for cProfile. It'll give you exact call counts and timings, which is great for tight loops or recursive code. The overhead is higher though.

  
  

• When you're dealing with something running in production , or hard to reproduce locally, Py-Spy is your go-to tool. You can attach it to a live process without restarting anything.

• And finally, if you want to get performance & memory at the same time, Scalene gives you per-line CPU, wall time, and memory usage in a single report. I discovered this tool recently, I need to dig deeper.

  
  

Performance is just one part of the story.
Next up: tackling memory usage, ORM madness, and other sneaky slowdowns. Stay tuned!

Did you learn something ? Subscribe for free to receive new posts

Since I do freelance work, I only work a few months each year to have more time to spend on my projects. And in 2024, I decided to go all in. Meaning that from November 2023 to today, I've only been working on my side projects.

Let's start from early 2024:

January 2024: pinock.io

For a few months, I had been working with a friend on a B2B tool called Pinock.io. It was designed for IT consulting firms (ESNs) that regularly present developer profiles to their clients. These companies often need to refine contractors resumes correcting errors, and reformatting them to match the company's branding and color scheme.

This process is tedious and time-consuming, so we built an automated tool to make it easier.

We started working on Pinock.io in mid' 2023, but by January 2024, we decided to stop. We weren't aligned on the timeline anymore, and we had exhausted ourselves. So, January was still dedicated to this project, but that was the end of it.

No regrets, though. I learned a lot from the experience and took valuable lessons from it.

February & Mars 2024 : blog.stuffandcode.com(this blog)

Over the years, I've created a few blogs. I've always liked sharing my knowledge and findings, and I've tried multiple times to keep a blog going. But that kind of work isn't for me. Yeah, that's ironic since I'm literally journaling on my blog right now.

The problem is, I get exhausted. I can't keep up with being consistent.

So I ran a blog for two months, focusing on Python specifically performance issues, how to identify them, and how to solve them. It's a topic I enjoy, and I wanted to create content in my mother tongue, French, since there are already amazing resources in English.

But I guess it was too niche. Python developers + performance issues + French readers... too narrow of an audience.

I eventually gave up because, why bother?


March 2024: Building a template for the next projects

In March 2024, I came across a French entrepreneur who was launching SaaS projects at lightning speed. He really inspired me. He kept saying that you shouldn't spend too much time on ideas, just build, launch, see if it works, and repeat.

Like most people, every time I built something, I wanted it to be perfect: beautiful UI, no bugs, scalable, fully tested. But doing that, you end up spending months instead of days or weeks. So I thought :
I've been doing things the same way for years, and it never worked. Let's try something different.

TK 2024

At first, it was hard. It felt messy. No tests? Come on bro'?

Some parts of my code looked awful and could've been refactored, but they worked, so why spend more time on something that would most likely never even be used? The first few weeks were rough. It didn't feel natural.

So I made a rule : from now on, my projects should take no more than two weeks to build.

So I've decided to take time to build an awesome template for my future projects. I've setup everything I need, here's a glimpse of the tech' stack.


(I built this tool early 2025, it's free to use, enjoy https://weuse.dev)

You can find out my board here.

I've setup all the sign up login logic, payments hooks, metrics, user management, monitoring, deployments ...

All I need to do is fork it, rename the occurrences and get started. And to deploy, it literally takes me 10 minutes, 8 to setup de VPS and 2 to deploy with Docker Compose, and Docker Swarm if I need horizontal scaling.

April 2024 : Interactive-Tailwind.com

Backend and deployment weren't really an issue for me, but the frontend? That's what took most of my time. I really didn't like it. And I sucked at it. Everything I built looked terrible and took me way too long.

I tried Vue.js, React, plain JavaScript, TypeScript... but none of them clicked. Then I discovered Svelte. It had a small learning curve, but it suited me well, plain JS, no unnecessary complexity. It was a good starting point.

But the real monster was still ahead.

CSS.

I've always hated it. I never got the hang of it.

I tried multiple times, bought a few courses, watched online tutorials. I managed to do some things, but the effort never felt worth the result. So I decided to try something different.

Tailwind.

I liked the idea of not leaving my HTML, of not having to name my elements with class names... but in the end, it was still CSS. So, back to square one.

I looked for practical online exercises to learn Tailwind, but I couldn't find anything that suited me. Then I remembered

The best way to learn is to teach others.

TK 2024 (Again)

So there I was, building a course to learn Tailwind CSS from scratch, even though I had no knowledge of it myself.

The UI looked terrible, but the concept was cool. I showed a target design, and users had to write Tailwind code to match it and move on.

Two weeks passed. I integrated payments and launched on Product Hunt.

Yeah, pretty sad. But I did not care, I learned a lot, I saw the whole process and I was ready to go on the next one. And I managed to get it done under 2 weeks. Success.

P.S: Don't be too sad, because actually, since then, https://interactive-tailwind.com has become my most successful project. But it had a lot of revamping throughout the months. That's for next time.

Here's a sneak peek on how it looks like today :

May 2024 : PushBeacon.com

To collect payments, I went with LemonSqueezy instead of Stripe because they act as a Merchant of Record (MoR). Basically, they handle all the tax stuff for you, which is a lifesaver when selling internationally. Doing it yourself is a real pain.

The problem is, LemonSqueezy doesn't have a mobile app. So I had no way of knowing when I got paid unless I kept checking my emails. And yeah, no way I was doing that.

I started looking for an easy way to send custom notifications to my phone. I didn't want to set up a Discord or Slack bot, and I keep most notifications disabled to avoid distractions, so I needed something else.

Then I thought, why not just build a super simple mobile app whose only job is to receive notifications I send it? Sounds fun. So I opened PyCharm, set up React Native with Expo, and after some bibidi bobbidi boo, I had an app in two weeks.

Releasing it on the stores was a nightmare, especially on iOS. I also spent way too much time on the landing page because I wanted users to instantly get what it was about, try it out, and see how in just a few seconds and a simple HTTP request, they could send notifications to their phones, tablets, or smartwatches.

Then I launched it on Product Hunt :

Daaamn! That's what I'm talking about! And the best part? I got my first two payments ever for this. It was a lifetime deal, 45€ each. Not crazy money, I know, but that psychological barrier was gone. I finally made money from something I built.

A few people subscribed to the monthly plan too, but it didn't take long before things went flat. Today, it's mostly just me and some friends using it to set up custom alerts for our own tools. I don't really plan on maintaining it, especially when Apple asks for 100 bucks a year just to keep the app live on the store.

So yeah, I'll keep using it as long as it works, but I'm not putting any more dev time into it.

Almost on Time... But Mobile is a Different Beast

The initial goal was to ship it in two weeks, and honestly, we were almost there. The app was up and running within that time. But mobile isn't like pure web SaaS. Getting approved on the stores, dealing with app signing, waiting for Apple's review it all adds extra delays. That alone stretched the timeline a bit more than expected.

It made me realize that launching a mobile app is a whole different game compared to a simple web product. Would I do it again? Maybe, not haha.


May & June 2024 : Make-Landing.com

No time to lose. I realized I was spending way too much time building landing pages, and when you look at it, most people use the same kind of layouts anyway. So why not create a landing page generator?

I went on a deep dive, scrolling and scraping a ton of beautiful websites built with Tailwind. I broke them down into components, Hero sections, Pricing, About, and so on.

Then I made those components available in VueJS, React, Svelte, and plain JS, and added a button to shuffle and generate landing pages with different themes.

You could just keep hitting the button until you found the perfect layout. Once you were happy with the result, you had to pay to download the source files.


Decided to launch on Product Hunt :

Back to square one. This project has been taken down since, it showed no interested, but again, my frontend skills improved.

June 2024: Couldn't code much

In June 2024, I had eye surgery on both eyes. For about two to three weeks, I couldn't really focus on screens. I was seeing double, which made it almost impossible to get anything done. So yeah, coding wasn't really an option that month, but I kept myself busy with other things.

July & August 2024 : Palantly.com

This time, I broke my own rule. I was spending the summer at a friend's place, so I wanted to enjoy it and take things slow.

As I started juggling multiple projects, I needed a way to track if everything was running smoothly. I had Plausible Analytics to monitor traffic on my websites, but I had no way of knowing if my backend services were actually working. Setting up backend analytics, with health checks, response times, and all that, is always a hassle. So I thought, why not build something simpler?

Like waaay simpler.

Something as easy as dropping a <script> tag on a website and that's it. Just like Plausible, but instead of tracking page views, it would track API calls and display everything in a clean, visual way. Nice graphs showing which routes were hit the most, how long they took, response statuses... all at a glance.

It was an interesting project because I got to play with new technologies, like ClickHouse. I went with it because I read some Plausible blog posts where they mentioned that Postgres wasn't ideal for this kind of workload long-term. A little pretentious to assume I'd hit the same scaling issues, but hey, why not do it right from the start?

I spent the summer working on it. The UI was clean, I spent a lot of time finding the right graphs, and everything was running smoothly. Whenever a user browsed one of my websites, it would track API calls, measure their response times, and periodically send the stats to my backend. It worked well.

The logo looked amazing (thanks TK), so I was all set to launch on Product Hunt.


Damn, that's harsh. But you know, as time goes by, more and more products are released on Product Hunt, there are a lot of competition, a lot of bots, so it's hard to have visibility. I kept using this for myself, it was useful for me. But today, I discontinued it. But i'm proud of it.


Wrapping Up -- Part 1

So yeah, we're only at August 2024, and there's still a lot more to cover. But this gives you a sneak peek into what I've been up to these past months, just building, testing ideas, seeing what sticks, stopping, and repeating.

I won't lie, it's exhausting. I know I should take longer breaks sometimes to avoid burning out, but until I can actually make a living from these projects, I don't really have that luxury. I know I'll get there eventually, but it takes time, effort, perseverance... and a bit of luck.

Writing this down helps too.

Thanks for reading.

See you soon! 🦝

TK.

If you're an OG you remember this ⬇️

I made this a while ago, like 3 years maybe, to try out to build something for me.

But for the new comers, what's Symfoz ?

Basically, it's an RSS aggregator. Where you could create custom feeds (playlists ) of content that you found interesting. Like resources about Python programming language 🙄 , or music, design etc... And everything is aggregated in this playlist, so you just have to check this.

You were able to add RSS feeds ofc, but also Youtube channels , Spotify shows, Twitter handles ... And the best, you were able to share your playlist with other and follow other.

Anyhow, I was not good at frontend, the UX was not incredible, so I kept it online for my most loyal user (Hey mom 👋).

And decided to take it down a few months ago.

But I felt sad about this.

So I've decided to revamp this tool, to add new features, try out new libs, and improve. And the best part ? I want to take you with me in this adventure.

See you soon !
If you don't want to miss new articles, just subscribe to my newsletter ! Or just wait for Symfoz to come out!

I've decided to pick up the blog where I left off. But when I reflected on what I'd done previously, I realized it was "too niche." By that, I mean it was aimed at:

• French-speaking people

• Python developers (mostly)

• Those interested in improving performance

• Readers of articles, blogs, or content about the subject

No need to say the target audience was pretty narrow. So I've decided to work on these aspects, and the first decision is to switch to English.

Don't worry, I'm not a native speaker, so I'll keep the vocabulary simple to make things easy to follow.

I'm not entirely sure what I'm going to write about yet. Maybe I'll document my journey building a SaaS, share examples of open-source contributions, or just post random stuff. I don't know. I guess we'll see.

Talk to you soon!

On entend souvent dire que Python est lent.

Mais entre nous, c'est plus nuancé que ça. En optimisant le code, il est possible de faire des merveilles sans avoir à dire adieu à Python.

Bien sûr, il est évident que les langages compilés , genre Rust, ont une longueur d'avance côté vitesse. Mais peu importe car Python peut embarquer ces langages tels que nous pouvons le voir dans des bibliothèques qui intègrent du C ou du Rust , comme Numpy ou Pydantic v2.

Disclaimer : J'ai commencé à faire du Rust très récemment, donc si j'ai raté des optimisations ou des bonnes pratiques, c'est normal.

Notre challenge : Advent Of Code 2022

Afin d'apprendre un nouveau langage, je trouve qu'il est pertinent de tenter de résoudre des problèmes concrets, et de monter en difficulté.

Pour ce faire j'ai décidé de prendre le Advent Of Code de 2022 et d'essayer de résoudre le challenge une première fois en full Python et une seconde fois en Python qui intègre du Rust afin de comparer les performances.

Pour plus de détails sur le défi, vous pouvez cliquer ici.

Je n'entrerai pas spécialement dans les détails techniques de la solution. Pour résumer l'énoncé, voici l'idée du challenge :

Nous avons une string contenant des calories pour différents elfes (univers de Noël). Nous devons trouver quel elfe possède le plus de calories. Le jeu de données ressemble à ceci :

1000
233

1000
1000
6000

400
... 

Dans ce cas là, c'est le deuxième elfe qui possède le plus de calories, avec 1000 + 1000 + 6 000 calories = 8 000.

Le résultat attendu est donc 8 000.

Notre implémentation en Python

Voilà, c'est presque du one-line. Concrètement on itère sur chaque bloc représentant un elfe (les double "\n"), on prend chaque ligne que nous convertissons en entier puis les additionnons ensemble.

Enfin, nous ordonnons la liste de sommes afin d'avoir le plus grand nombre en premier .

Tadaaaa ! Nous savons quel est le maximum de calories parmi ces elfes.

Réécrire notre logique en Rust

Et maintenant, place à Rust.

On va utiliser une librairie appelée rustimport . Cet outil nous facilite la vie en compilant notre code Rust pour qu'il puisse être utilisé dans notre script Python, grâce à PyO3.

Rust bindings for Python, including tools for creating native Python extension modules. Running and interacting with Python code from a Rust binary is also supported.

Tiré de https://github.com/PyO3/pyo3

Voici notre fichier aoc.rs

Nous avons défini une fonction "compute" qui prend en paramètre du texte et qui réalise les mêmes traitements que notre script Python précédent.

Pour avoir plus de détails sur la syntaxe adéquate afin d'utiliser votre script dans votre programme Python, je vous renvoie vers la documentation.

Maintenant, voici à quoi ressemble notre script Python qui utilise ce fichier aoc.rs

Vous pouvez voir que le tout premier import vient de rustimport.

Qu'est-ce que rustimport.import_hook ?

C'est une ligne de code qui va permettre de regarder dans notre dossier s'il y a des fichiers .rs, et de les compiler afin d'être utilisables par Python.

Par exemple, nous avons un fichier aoc.rs , ce qui signifie que notre module Python s'appelle "aoc".

Ensuite, nous pouvons appeler la méthode "compute " de aoc pour faire les calculs.

Si vous appréciez la newsletter StuffAndCode, vous pouvez vous inscrire afin de ne manquer aucun article !

🐍 Et recevez en PLUS, un article exclusif sur comment profiler n'importe quel type de code Python.

Abonnez-vous maintenant

Mesurons les performances

Pour cette occasion, j'ai décidé de mesurer le temps d'execution des deux fonctions "main" de mes scripts. Ceci exclutle temps de compilation mais mesure uniquement le temps d'execution de notre fonction.

On recommence cette opération 1 000 fois, on calcule la moyenne du speedup de Rust par rapport a Python et également l'écart type pour voir si les résultats sont proches.

En lançant notre comparatif nous avons ces résultats là :

`Results :
Mean Speedup: 1.1833177238773642
Standard Deviation: 0.06543422441011415`

WTF ? Rust est uniquement 1.18 fois plus rapide que Python ?

C'est étonnant, ne trouvez-vous pas ?

Et si ! Effectivement, il y un tips à savoir, un piège à éviter. Lorsqu'on compile "normalement" notre script Rust, le compilateur va générer une version "Debug" de notre script, et non pas une version optimisée telle qu'elle serait en production.

Pour ce faire, il suffit d'ajouter une ligne dans notre script Python pour préciser que nous voulons activer le build optimisé.

Et là, en relançant la mesure du temps, nous obtenons des résultats plus proches de ce qu'on espérait. Un speedup de quasiment x10.

Results :
Mean Speedup: 9.970547291038583
Standard Deviation: 0.44621048695561444

Aller plus loin

Comme je l'ai mentionné au début de cet article, je suis un débutant en Rust. Mais je suis sûr qu'avec plus d'expertise, les gains seraient bien plus importants.

A titre d'expérience, j'ai demandé à GPT de m'écrire une version optimisée de mon code. En parallèle, j'ai vérifié que les résultats étaient les mêmes.


J'ignore exactement ce qu'il se passe dans ce code, mais en l'executant nous obtenons les résultats suivants :

Results :
Mean Speedup: 21.137375292664284
Standard Deviation: 0.9441126168701539

Notre script Rust est 21x plus rapide que notre fonction Python originale ! C'est assez impressionant ! Nous avons plus que doublé les performances de notre version Rust initiale.

Conclusions

1. Intégration de fonctions Rust dans Python : Nous avons vu que l'intégration de fonctions Rust dans des programmes Python est plus accessible qu'il n'y paraît.

2. Gains de performance : L'utilisation de Rust peut offrir des avantages significatifs en termes de performance.

   Ces gains de performance peuvent être utilisés pour optimiser certaines parties d'applications Python, des bottlenecks.

3. Ajout d'options pour optimiser la performance : En utilisant rustimport, il est essentiel d'ajouter certaines options spécifiques telles que "compile_release_binaries" lors de vos tests, sinon les résultats ne seront pas représentatifs du gain réel.

Cependant, il est important de noter que rustimport est un outil pour faciliter le prototypage, et savoir rapidement si intégrer Rust vous sera bénéfique.

Si vous comptez réellement utiliser du Rust dans votre codebase, vous devrez le packager plus proprement; de la même manière si vous souhaitez utiliser des 3rd party librairies Rust, vous devrez également ajouter de la configuration.

ET tout cela sera l'occasion d'un prochain article !

Si vous appréciez la newsletter StuffAndCode, vous pouvez vous inscrire afin de ne manquer aucun article !

🐍 Et recevez en PLUS, un article exclusif sur comment profiler n'importe quel type de code Python.

Abonnez-vous maintenant


Lorsque nous développons des services destinés à être utilisés avec un certain volume, il est crucial de tester notre code.

Les tests unitaires, fonctionnels, d'intégration et end-to-end, sont souvent mis en place dans les projets. C'est très bien, mais nous pouvons aller encore plus loin afin d'être plus serein.

Le load testing (test de charge en français).

L'idée est d'envoyer un grand nombre de requêtes à notre service pour observer sa réaction face à la charge.

Cela inclut l'évaluation de la capacité d'absorption de la charge, du changement des temps de réponse, des éventuelles erreurs dans les réponses, et des comportements inattendus.

Cela permet aussi de déterminer le nombre maximal d'utilisateurs simultanés, afin d'ajuster le sizing ou le nombre de nos machines (vertical scaling vs horizontal scaling).

De plus, ces tests fournissent des informations sur la latency (temps nécessaire pour compléter une action) versus le throughput (nombre d'opérations par unité de temps).

Voici ce magnifique GIF que j'ai réalisé avec la librairie Motion Canvas. Il y a encore un peu de boulot mais voici une illustration de la différence entre Latency et Throughput.

Je vais vous parler de la librairie Locust , une bibliothèque Python permettant de faire du load testing en Python. Locust peut être utilisé via la ligne de commande ou une interface web.

❓Petit moment culture : Locust veut dire Sauterelle / Criquet pour rappeler les 10 plaies d'Egypte. L'idée sous-jacente est que Locust envahit notre API comme les sauterelles ont envahi l'Egypte tel que décrit dans le livre de l'Exode.

Avec Locust, on définit le nombre de connexions simultanées souhaitées (par exemple, 1 000 pour simuler mille utilisateurs), et également un "ramp-up" pour augmenter progressivement la charge. Si nous choisissons de tester 100 connexions simultannées avec un ramp-up de 10 utilisateurs, cela signifie que chaque seconde, nous ajoutons 10 utilisateurs pour monter progressivement la charge.

Nous pouvons choisir les endpoints à cibler et leur attribuer des poids relatifs. Locust permet également de définir un "wait_time " pour simuler de manière plus réaliste le comportement d'un utilisateur, en introduisant des pauses entre les requêtes.

Tester notre première API

Sans plus attendre, voici un exemple. Nous avons une application FastAPI simple avec une seule route sur "/". Nous voulons évaluer combien de requêtes peuvent être gérées par cette application, sur mon ordinateur.

Nous utilisons la commande suivante pour démarrer notre API :

uvicorn app:app --workers 32

J'ai choisi 32 workers car mon ordinateur a 32 cœurs.

Apparemment, la formule idéale serait le nombre de CPU * 2 + 1, donc 65 dans mon cas. Mais n'ayant pas constaté de gain de performance, j'ai gardé 32 workers.

Si vous appréciez la newsletter StuffAndCode, vous pouvez vous inscrire afin de ne manquer aucun article !

🐍 Et recevez en PLUS, un article exclusif sur comment profiler n'importe quel type de code Python.

Abonnez-vous maintenant

Ensuite, écrivons notre premier test de charge avec Locust.

Nous créons une classe qui hérite de HttpUser, instanciée pour chaque utilisateur.

Par exemple, avec 1000 utilisateurs, cette classe sera instanciée 1000 fois.

Nous définissons une seule tâche avec le décorateur @task.

Si plusieurs tâches sont définies, Locust les choisit aléatoirement . Dans le test test_home_page, on utilise self.client.get("/").

Pour spécifier l'host , nous pouvons utiliser une variable d'environnement ou l'interface web de Locust.

Pour ce tutoriel, j'utilise l'interface web, parce que : why not ?

Après avoir écrit notre test, démarrons Locust avec la commande :

`locust -f locustfile_part1.py --processes -1 --modern-ui`

• L'option -f précise le fichier à exécuter.

• --processes -1 permet d'utiliser tous les processeurs disponibles sur notre machine pour envoyer le plus de requêtes possible

• L'option --modern-ui utilise une interface web, plus sympa, qui est encore en beta

Sur la page Locust, nous définissons :

• le nombre d'utilisateurs à simuler.

• le ramp-up par seconde.

• la durée du test.

  
  

Par exemple, nous pouvons monter à 1000 utilisateurs, envoyer des requêtes pendant 30 secondes, puis arrêter, en spécifiant ces paramètres dans les champs appropriés.

Voici à quoi ressemble l'écran de configuration de notre test de charge.


J'ai configuré le test pour évaluer notre route avec 1 000 utilisateurs, sans spécifier de délai entre les requêtes. Ci-dessous, les résultats.


Les résultats ne montrent aucune erreur sur nos routes, des temps de réponse constants , et pour 1 000 utilisateurs simultanés, nous atteignons un peu plus de 20 000 requêtes par seconde.

Vous pouvez consulter ces résultats dans les tableaux ou graphiques, télécharger les données, consulter les logs, et voir le nombre de requêtes traitées par chaque worker.

Maintenant, passons à quelque chose de plus concrêt.

Une API protégée par du "JWT"

Je vais simuler une API REST utilisant un JWT. Pour simplifier, je considérerai qu'un header avec un Bearer token est valide pour l'authentification.

Voici le code de notre "API REST" :

Nous disposons de trois routes :

1. Le login qui renvoie un token.

2. Deux routes identiques simulant une ressource protégée.

Dans notre test Locust :

La méthode on_start est utilisée pour définir une action spécifique au moment de la création d'un nouvel utilisateur. Par exemple, chaque nouvel utilisateur envoie une requête sur /login pour récupérer un token, nécessaire pour s'authentifier sur les autres routes.

Nous avons ensuite deux autres tâches envoyant des requêtes sur les routes protégées. Nous avons décoré notre deuxième route avec @task(3). Cela nous sert à donner un poids , c'est à dire que cette route a trois fois plus de chances d'être appelée que la première. Car pour rappel, Locust regarde toutes les méthodes décorées de @task puis choisit de manière random.

L'attribut wait_time de la classe définit un intervalle aléatoire entre 1 et 5 secondes entre chaque tâche, afin de simuler un comportement utilisateur plus réaliste.

Conclusion

En conclusion, je voudrai souligner que Locust offre des possibilités plus avancées :

• envoyer des requêtes depuis plusieurs machines pour simuler des millions d'users.

• Bien que nous ayons testé une API REST dans cet article, Locust permet de tester plusieurs protocoles en utilisant différents clients. Plus d'informations sur ces clients sont disponibles ici.

Finalement, il est important de noter que j'ai exécuté le test de charge et l'API sur la même machine par simplicité, mais cela a clairement influencé les résultats.

Cela permet tout de même de détecter des bugs potentiels et d'avoir une vue globale. Pour pousser au maximum l'expérience, il faudrait exécuter le load testing sur une machine distincte.

Si vous appréciez la newsletter StuffAndCode, vous pouvez vous inscrire afin de ne manquer aucun article !

🐍 Et recevez en PLUS, un article exclusif sur comment profiler n'importe quel type de code Python.

Abonnez-vous maintenant

Dans le développement, la mise en place de tests est une étape incontournable.

Qu'ils soient unitaires, fonctionnels ou end-to-end, les tests garantissent la qualité et la fiabilité du code. Cependant, à mesure que notre codebase s'élargit, le nombre de tests augmente, entraînant une augmentation significative du temps de test.

Cette situation a deux conséquences principales :

• une perte de temps directe pour le développeur.

• dans le cas de pipelines de CI, des coûts accrus liés au temps d'exécution des tests.

⚠️ Dans cet article, nous allons utiliser SQLlite en tant que base de données, mais cela fonctionne de la même manière si vous utilisez une autre base de données tels Postgres ou MySQL ou autre.

Il suffit de changer l'URL lors de la création de l'engine SQLAlchemy. Par exemple :

Accélérer les tests

Plusieurs stratégies peuvent être adoptées.

Par l'optimisation des tests eux-mêmes, en observant ce qui prend du temps, peut-être même revoir le scope des fixtures etc... Mais cette approche a plusieurs limites, dont la première : si le code à tester est long, malgré l'optimisation des tests, il y aura peu de différence.

La méthode la plus simple et la plus efficace semble être la parallélisation des tests. L'idée est de lancer plusieurs tests simultanément au lieu de les exécuter les uns aprés les autres.

Parallélisation avec Pytest-xdist

Pytest-xdist est un outil Python qui facilite cette parallélisation. L'utilisation de cet outil est simple : si vous disposez de 32 CPU, vous pouvez théoriquement exécuter jusqu'à 32 tests simultanément.

Cette capacité à exécuter des tests en parallèle peut grandement améliorer le temps nécessaire pour lancer votre suite de tests.

De plus, la mise en place est très facile :

>> pip install pytest-xdist

>> pytest -n auto

La commande pytest -n auto va détecter automatiquement votre nombre de CPU afin de pouvoir créer le nombre approprié de workers ,et démarrer les tests sur ceux-ci.

Les side-effects et la parallélisation

Cependant, la parallélisation soulève un défi de taille : la gestion des side effects. Certains tests peuvent modifier des ressources externes, comme des fichiers ou des bases de données, polluant ainsi les l'environnements pour d'autres tests.

Par exemple, un test créant des instances dans une base de données peut laisser des traces qui affecteront les tests suivants.

C'est un problème connu : lorsqu'on execute des tests qui se servent d'une base de données, nous devons nettoyer cette base de données entre chaque test.

Nettoyer sa base de donnée après chaque test

Pour remédier à cela, deux approches principales sont souvent utilisées :

• l'utilisation de rollbacks en fin de test

• la suppression de la base de données après chaque test.

  
  

Afin d'illustrer nos exemples, nous allons partir du model SQLAlchemy que nous désirons tester :

1) Tests sans nettoyage des données

Nous avons deux tests : un qui crée un Book et qui vérifie qu'il existe bien un seul Book; un second test qui crée 5 Books et qui vérifie qu'il en existe 5. Ces tests sont simples mais ils vont permettre d'illustrer nos propos.

Si j'execute de manière séquentielle (l'un aprés l'autre) mes tests, je vais d'abord créer 1 Book . Le test va passer. Mais lors du deuxieme test, je vais créer 5 books supplémentaires, sans avoir nettoyé ma base de données, en supprimant le book de l'ancien test. Par conséquent, au lieu d'avoir 5 books j'en aurai 6.


Donc, il nous faut un moyen de remettre notre database en état entre chaque test pour éviter les pollutions.

2.1) Utilisation de rollback à la fin du test

Afin d'éviter la pollution de test, une solution souvent préconisée est de réaliser un "rollback" à la fin de notre test, de sorte que toutes les actions réalisées dans la transaction courante soient annulées.

On peut donc ajouter ce comportement directement à notre fixture.

Essayons ce code ci :

Voici les résultats de ces tests :

Comme vous pouvez le constater, les tests ne passent pas. Pourquoi ?

Tout simplement parce que, même si nous faisons un "rollback" à la fin du test dans notre test, apparaissent des commits pour seeder nos tests, et donc ces changements sont persistés en base de données au moment du commit.

Ainsi, dès que le test fait un commit, le rollback n'aura plus d'effet car les résultats auront déjà été persisté en base de données.

2.2) Un hack pour rollback

Il existe effectivement un "hack" pour rollback entre chaque test.

Mais ceci dépasse le scope de cet article. Je vous renvoie à l'article qui l'aborde en cliquant ici.

Pour plus de détails, vous pouvez directement vous rendre sur la page de SQLAlchemy qui détaille son fonctionnement en suivant ce lien.

Si vous souhaitez simplement mettre en place le rollback dans vos tests, je vous transmets ci-dessous la fixture telle qu'elle est préconisée dans l'article :

Si vous appréciez la newsletter StuffAndCode, vous pouvez vous inscrire afin de ne manquer aucun article !

🐍 Et recevez en PLUS, un article exclusif sur comment profiler n'importe quel type de code Python.

Abonnez-vous maintenant

3. Drop la base de données

Pourquoi ne pas tout simplement créer et supprimer la base de données lors de chaque test ? Ca nous permettrait d'être sûr d'avoir un environnement propre !

Nous pouvons mettre en place ce mécanisme comme vous pouvez le voir ci-dessous.

Nos tests passent, c'est bien. Mais à cette approche, incombent certains problemes.

3.1) Les problématiques de cette approche

Supprimer et recréer la database pour chaque test prend du temps, et cela peut rallonger considérablement le temps d'execution de vos tests.

Si vous parallelisez vos tests, cela veut également dire que lorsqu'un test va terminer, il va modifier les données et polluer un autre test, également drop la base de données, pendant que les autres tests finissent de s'executer. Ce qui va générer des erreurs:

3.2) La Solution : Créer une base de données par worker

Lors de l'utilisation de Pytest-xdist, un nouveau problème émerge : si chaque test parallélisé tente de modifier la même base de données, des conflits surviendront inévitablement.

La solution réside dans la modification de notre fixture de base de données pour créer une base distincte pour chaque worker . Ainsi, chaque worker opère sur sa propre base de données, et évite les conflits tout en bénéficiant d**'un véritable parallélisme**.

Pour ce faire, pytest-xdist ajoute une variable d'environnement "PYTEST_XDIST_WORKER" qui attribue une valeur pour chaque worker. Par exemple, si nous avons 10 workers, chaque worker aura une variable PYTEST_XDIST_WORKER qui vaudra 0, 1, 2 ... 9.

Nous pouvons donc créer une base de données pour chaque worker en nous servant de cette variable d'environnement, résultant en un environnement isolé pour chaque worker.


Cela fonctionne !

Cependant, vous pouvez noter que le temps est tout de même passé de +3s contre 0.23s pour la version séquentielle. La raison ? Démarrer les tests sur plusieurs CPU prend du temp s !

Donc si vos tests sont déjà trés rapides de manière séquentielle, il est peut-être plus pertinent d'éviter de mettre en place la parallélisation.

A l'inverse, si vos tests sont plus longs, le gain de temps peut-être vraiment très intéressant.

Quizz Time

• Quelle librairie utilisons-nous pour paralleliser nos tests ?

• Dans quel cas est-il préférable de ne pas paralleliser les tests ?

• Quels sont les avantages et inconvénients de drop la database entre chaque test ?

Si vous appréciez la newsletter StuffAndCode, vous pouvez vous inscrire afin de ne manquer aucun article !

🐍 Et recevez en PLUS, un article exclusif sur comment profiler n'importe quel type de code Python.

Abonnez-vous maintenant

C'est une belle journée d'été, tout est calme; un peu trop calme peut-être.

Notre système de monitoring ne signale aucune erreur, alors que d'ordinaire, nous recevons quelques alertes Sentry par jour. Mais là, c'est silence radio, et c'est suspect.

En examinant nos données, nous nous rendons compte qu'il ne se passe rien depuis plusieurs heures. Pourtant, notre programme est configuré pour redémarrer automatiquement en cas de crash.

Nous nous précipitons sur la machine et exécutons un docker ps pour vérifier si les conteneurs fonctionnent toujours. Oui, ils sont opérationnels.

Alors, que se passe-t-il ? Pourquoi l'activité semble-t-elle arrêtée ?

Let's debug this sh*t.

Welcome to py-spy

py-spy is a sampling profiler for Python programs. It lets you visualize what your Python program is spending time on without restarting the program or modifying the code in any way. py-spy is extremely low overhead: it is written in Rust for speed and doesn't run in the same process as the profiled Python program. This means py-spy is safe to use against production Python code.

Tiré de https://github.com/benfred/py-spy

Les points fort de py-spy

La librairie permet de réaliser plusieurs actions intéressantes :

• Profiling de code : C'est un statistical profiler.

• Capacité à se brancher directement sur un processus en cours d'exécution sans nécessiter de modification du code, ou de redémarrage de l'instance.

• Prise en charge du multiprocessing : Gestion efficace des environnements utilisant le multiprocessing, les workers gunicorn, etc...

Notre premier script à debug

Voici notre premier coupable : un script se retrouve stuck dans une boucle infinie et qui exécute time.sleep sans cesse.

Nous allons exécuter ce script sur notre host, et observer quelles informations émergent.

Après l'avoir lancé, nous récupérons le PID de notre processus, une information cruciale pour établir la connexion avec py-spy.

py-spy offre actuellement trois commandes principales pour recueillir les informations sur notre processus.

Explorons-les !

1. py-spy dump

py-spy offre la possibilité d'afficher la call stack actuelle de chaque thread Python avec la commande dump.

Nous avons également la faculté d'ajouter un flag ---locals afin de voir les variables et leurs valeurs actuelles.

py-spy dump --pid 70300

Dans cet exemple, nous observons que le blocage se situe à la ligne 7 et correspond effectivement à notre instruction time.sleep.

2. py-spy record

Nous avons aussi la possibilité de nous connecter au processus, et de réaliser un enregistrement (record) sur une durée plus étendue.

Lorsque nous estimons avoir collecté suffisamment de données, un simple appui sur Ctrl + C interrompt le profiling. Cette action génère un flamegraph, un visuel qui illustre où le code consacre la majorité de son temps d'exécution.

Exemple de commande pour lancer le record :

py-spy record ---pid 8773

Le flamegraph se lit de haut en bas.

Dans notre cas, il confirme effectivement que la ligne 7 ( notre fameux time.sleep ) monopolise le temps d'exécution. Sans surprise !

Si vous le souhaitez ,vous pouvez visualiser ces résultats autrement; avec un speedscope par exemple, le lien est ici.

Si vous appréciez la newsletter StuffAndCode, vous pouvez vous inscrire afin de ne manquer aucun article !

🐍 Et recevez en PLUS, un article exclusif sur comment profiler n'importe quel type de code Python.

Abonnez-vous maintenant

3. py-spy top

py-spy propose la commande top afin de suivre le déroulement de notre programme. Nous pouvons lire les fonctions appelées, le temps d'execution etc ...

Et c'esten temps réel ! Donc nul besoin d'être à l'aveugle comme sur la commande record, ou d'avoir juste un point dans le temps avec la commande dump. Ici nous visualisons directement ce qu'il se passe dans notre programme.

Cependant, nous pouvons constater que nous ne voyons pas exactement le numéro de la ligne executée par le programme.

Un cas concret

Nous sommes en 2k24, nos services tournent dans des containers et le code est légèrement plus compliqué qu'une boucle while avec un sleep. On va essayer de randomiser tout cela afin de simuler une anomalie, sans qu'elle produise un blocage complet.

Nous allons exécuter ce code dans un conteneur Docker utilisant Python 3.11, et rechercher où notre code consacre le plus de temps.

1. Debugger depuis l'host

Notre code tourne dans un container Docker , mais rien ne nous empêche de le debugger depuis notre host .

Pour cela rien de plus simple. Nous cherchons le PID de notre processus Python qui tourne dans Docker, et nous lançons les mêmes commandes que nous avons vues précedemment.

Il est fort probable que vous deviez exécuter la commande avec les droits root pour mener les observations.

De la même manière, nous pouvons faire un record de programme, toujours pour mettre en évidence les actions, et analyser le flamegraph.

2. Debugger depuis Docker

Envisageons que vous ne vouliez/puissiez installer py-spy sur votre machine hostde production. Peut-être n'avez-vous pas de version Python compatible avec ?

Pas de soucis ! Nous pouvons debugger à l'aide de Docker.

Scénario 1 : se servir du container de notre programme

Py-spy est reconnu pour être low-overhead. Donc il aura un faible impact sur les performances de notre programme, et prendra peu de ressources de notre container.

Ainsi, nous pouvons imaginer ce scénario :

• Entrer dans le container avec la commande docker exec -ti <container_name> bash

• Installer py-spy : pip install py-spy

• Trouver le PID de notre programme

• Lancer le debug avec la commande py-spy top par exemple

Nous avons un plan, testons le :

WTF ? Nous avons une "Operation not permitted" alors que nous sommes root ?

py-spy offre de la documentation à ce sujet que vous pouvez retrouver ici .

On nous dit :

Running py-spy inside of a docker container will also usually bring up a permissions denied error even when running as root.

This error is caused by docker restricting the process_vm_readv system call we are using. This can be overridden by setting --cap-add SYS_PTRACEwhen starting the docker container.

Alternatively you can edit the docker-compose yaml file

`your_service:
   cap_add:
     - SYS_PTRACE
`

Note that you'll need to restart the docker container in order for this setting to take effect.

Donc, il est explicitement écrit dit que si l'on désire debugger notre programme dans Docker , il fautajouter des capabilitie s et redémarrer notre container.

Ce n'est vraiment pas incroyable, vu que potentiellement le bug se produit trés rarement, et ignorons quand il va se reproduire.

Aussi, devoir faire des modifications de docker-compose juste pour çela, ce n'est pas fou.

✨Soyez serein,nous avons une autre solution ! ✨

Scénario 2: Debug depuis un autre container Docker

Pourquoi pas démarrer un autre container en lui ajoutant la capability nécessaire pour profiler le code ?

Dans ce cas, nous devons partager le namespace du container que nous voulons debugger dans la commande afin que notre container de debug puisse cibler le processus à debugger.

Nous pouvons utiliser la commande suivante :

docker run --cap-add=SYS_PTRACE --pid=container:<container_name> -it python:3.11 /bin/bash

Une fois a l'intérieur du container, il suffit d'installer py-spy et de lancer nos commandes.

py-spy top --pid 1

Bingo ! Nous voyons l'activité de notre autre container !

Choses à noter :

• Limitation de Version Python : Actuellement, il est impossible de debug des programmes Python avec une version supérieure à 3.11 en utilisant py-spy, car il ne supporte pas encore ces versions.

  
  

• Fonctionnalités Étendues de py-spy : Les capacités de py-spy vont bien au-delà de ce qui a été présenté ici. L'outil offre une multitude d'options pour le debug, notamment la prise en charge du multiprocessing, la possibilité de trier les instructions qui retiennent le Global Interpreter Lock (GIL), ainsi que l'observation des processus IDLE.

  
  

• Interprétation des Résultats : en plus de flamegraph, py-spy propose également d'autres visualisations et outils d'analyse.

Si vous appréciez la newsletter StuffAndCode, vous pouvez vous inscrire afin de ne manquer aucun article !

🐍 Et recevez en PLUS, un article exclusif sur comment profiler n'importe quel type de code Python.

Abonnez-vous maintenant


Qu'est-ce que slots ?

TL;DR: __slots__ en Python est utilisé pour limiter les attributs qui peuvent être définis dans une classe.

__slots__ est un attribut de classe qui contient généralement des strings.

Lorsque __slots__ est défini dans une classe, les instances de cette classe ne peuvent avoir que les attributs spécifiés dans __slots__.

L'utilisation de __slots__ peut être utile pour économiser de l'espace mémoire en limitant le nombre d'attributs d'une instance.

Par exemple, si une classe n'a besoin que de quelques attributs et que nous savons que nous n'aurons pas besoin d'ajouter des attributs de manière dynamique, il peut être avantageux de les spécifier dans __slots__ .

Une classe normale


Nous pouvons accéder à l'attribut __dict__ et également assigner un nouvel attribut dynamiquement sans soucis.

Une classe avec slots


Ici, nous avons défini __slots__ avec un tuple qui contient une string "x ", ce qui signifie que nos instances ne pourront avoir qu'un seul attribut qui s'appelle x . Avoir d'autres attributs est impossible.

Par exemple, en regardant la ligne 9, si l'on essaie d'assigner un autre attribut comme ce que nous avons fait dans l'autre classe nous allons obtenir une AttributeError.

De la même manière, comme nous l'avons expliqué, l'attribut __dict__ n'existe pas dans ce contexte et génère donc un AttributeError.

Si vous utilisez des dataclasses, vous pouvez également utiliser __slots__ facilement, et ceci aura le même effet que précédemment.

Si vous appréciez la newsletter StuffAndCode, vous pouvez vous inscrire afin de ne manquer aucun article !

🐍 Et recevez en PLUS, un article exclusif sur comment profiler n'importe quel type de code Python.

Abonnez-vous maintenant

Mesurons les performances

Nous allons comparer deux scripts qui font la même chose.

La seule différence est que l'attribut "x " sera défini dans le __slots__ du deuxième script.

Voici notre premier script :

Et voici notre second script :

Si l'on décide de profiler avec cProfilenos scripts, nous obtenons ces résultats :


Nous pouvons constater un gain de performance de 1.24x plus rapide ou 23.53% plus rapide en spécifiant le __slots__.

Mesurons la mémoire

Nous l'avons dit, un des intérets de __slots__ est surtout lorsque nous avons beaucoup d'instances de cet objet là.

Nous avons vu que c'était déjà bien plus rapide, mais qu'en est t-il de la mémoire que nous pouvons économiser ?

Pour ceci nous allons mesurer avec un profiler de mémoire appelé "filprofiler".

Voici les résultats pour la version sans __slots__

Et voici les résultats avec __slots__

Le résultat est flagrant, nous avons donc une consommation de mémoire 1.82 fois moindre, soit une réduction de 54.8%, ce qui est assez énorme.

Il faut cependant se rappeler que dans ce cas précis nous avons 1 million d'instances. Ce qui peut potentiellement vous arriver en fonction de votre cas d'usage.

Si jamais vous avez peu d'instances, vous ne verrez pas un gain de performance aussi élevé que ce que nous avons obtenu.

Vous pouvez trouver plus de documentation ici.

Quizz Time

Allez, c'est parti pour quelques petites questions :

• Quels sont les intérêts d'utiliser __slots__ ?

• Que met-on dans l'attribut de classe __slots__ ?

• Quand pouvons-nous profiter au maximum de l'utilisation de __slots__ ?

• Qu'avons nous utilisé pour profiler la mémoire ?

Si vous appréciez la newsletter StuffAndCode, vous pouvez vous inscrire afin de ne manquer aucun article !

🐍 Et recevez en PLUS, un article exclusif sur comment profiler n'importe quel type de code Python.

Abonnez-vous maintenant

Le problème

J'ai voulu écrire un script qui me permet de détecter quels sont les pixels les plus fréquents sur un ensemble d'images. Est-ce le blanc, le noir, d'autres ?

Lorsque nous travaillons sur un petit volume d'image, ce n'est pas un souci, Mais lorsque le volume d'images augmente, par exemple pour des dizaines d'images, le temps de traitement devient un enjeu significatif.

Nous allons voir dans cet article comment à partir d'un script le plus simple possible mais peu performant, nous pouvons arriver à un script aux performances bien plus élevées.

1. La version naïve

Partons du principe que nous voulons télécharger 200 images, et les analyser pour compter les pixels les plus fréquemment rencontrés. Nous pourrons donc identifier les couleurs dominantes.

Note : Pour garantir une constance dans les résultats lors des benchmarks, j'ai choisi d'héberger les images localement.

De plus, j'ai mis en place un délai artificiel de 100ms pour simuler une connexion à un site distant. Cette simulation nous aide à mieux représenter les conditions réelles d'une application en ligne.

Note : La performance de chaque script a été évaluée dans un environnement contrôlé, sur la même machine et dans des conditions aussi similaires que possible.

Pour cela, j'ai développé un script, qui exécute chaque script à tester 5 fois* et mesure le temps d'exécution grâce à la fonction time.perf_counter.*

Nous calculons ainsi la moyenne (mean) et l'écart-type (stdev) des temps d'exécution pour obtenir une évaluation précise des performances.

Ces données nous permettent de comparer les scripts de manière plus nuancée et détaillée.

Aussi, nous mettons en avant le temps d'accélération par rapport à la version initiale du script. C'est pourquoi la première version, étant notre point de référence, présente un facteur d'accélération (speedup) de 1x.

Un speedup 1 signifie donc une dégradation des performances par rapport au script initial.

Voici notre script initial :

Je vous invite à regarder les extraits de code qui vous seront montrés tout au long de cet article et d'essayer d'observer quelles sont les différences entre chaque version. Cela vous donnera une meilleure compréhension globale et vous habituera aux syntaxes utilisées.

Ce script est certainement la manière la plus naïve d'écrire une solution pour ce problème. On itère sur chacune des URL, on récupère l'image (sans la stocker), et une fois toutes les images acquises, on itère dessus pour comptabiliser les pixels et enrichir un dictionnaire. Ensuite, nous utilisons l'objet Counter du module collections afin d'obtenir les pixels les plus courants.

Lorsque nous mesurons le temps d'exécution de ce script nous constatons :

v1: Mean = 59.17s, Stdev = 9.09s, Speedup = 1.00x

Ce temps semble assez long (pratiquement 1 minute pour traiter 200 images), tentons d'optimiser cela.

2. La version asynchrone

Nous avons vu que la première étape consiste à télécharger des images en masse; c'est typiquement une problématique IO, et les images sont indépendantes les unes des autres. C'est un bon candidat afin d'ajouter de la concurrence.

Nous allons continuer à utiliser le module httpx, mais nous allons l'utiliser en mode asynchrone avec le module asyncio afin de pouvoir envoyer plusieurs requêtes en même temps.

On peut facilement exécuter les 200 coroutines en simultanées grâce à asyncio.gather et récupérer tous les résultats d'un coup.

Voici les résultats pour ce script :

tutov2: Mean = 38.85s, Stdev = 0.27s, Speedup = 1.52x

Sans trop de surprises, nous avons gagné 20 secondes, car il y a 200 images qui répondent avec un délai d'au moins 100ms. Voici un bon début.

Voyons voir si nous pouvons mieux faire.

3. Utilisation de ProcessPoolExecutor

Nous avons réussi à implémenter de la concurrence afin de pouvoir réduire le temps de téléchargement des images. Pouvons_nous faire mieux en rajoutant du parallélisme dans notre programme ?

Lorsque nous parcourons nos pixels et les comptons, c'est une problématique de calcul. Donc CPU et non plus IO. Cette fois asyncio ne nous sauvera pas.

De la même manière le module threading est inadapté aux problématique CPU à cause du GIL (Global Interpreter Lock), qui, pour rappel, empêche plusieurs instructions Python de s'exécuter en même temps au sein d'un même Process.

Ainsi nous allons utiliser le module concurrent.futures, et l'excellentProcessPoolExecutor qui nous permet de mettre en place du multiprocessing facilement et d'ajouter du parallélisme à notre programme.

Si vous appréciez la newsletter StuffAndCode, vous pouvez vous inscrire afin de ne manquer aucun article !

🐍 Et recevez en PLUS, un article exclusif sur comment profiler n'importe quel type de code Python.

Abonnez-vous maintenant

Merci de lire StuffAndCode Newsletter ! Abonnez-vous gratuitement pour recevoir de nouveaux posts et soutenir mon travail.

Note : Lorsqu'on démarre un process Python, il y a un main Thread qui s'exécute et le GIL est présent dans chacun des processes. Si nous démarrons plusieurs processes avec un seul Thread, chacun aura son propre GIL. Ainsi, ils ne se gêneront pas ,et nous obtiendrons du vrai parallélisme. Cependant, démarrer des processes est plus couteux que de démarrer des Threads. De même concernant le transfert des données entre processes.

Voici une implémentation de "comment paralléliser le comptage des pixels sur plusieurs processeurs".

Nous avons également remplacé le système de dictionnaire pour compter directement avec le Counter.

Voici les résultats pour cette version.

tutov3: Mean = 12.01s, Stdev = 0.68s, Speedup = 4.93x

On peut noter une amélioration significative du temps d'exécution.

Nous obtenons 12 secondes contre 59 secondes lors de la première version.

En cas de doute quant à la pertinence de ProcessPoolExecutor ou de ThreadPoolExecutor , sachez que vous pouvez le changer facilement, puis relancer le programme afin de mesurer. Dans mon cas le programme avec le ThreadPoolExecutor prenait 18 secondes au lieu de 12 secondes.

Ce qui signifie que l'ajout du ProcessPoolExecutor est bénéfique.

4. Amélioration de notre Counter

Okay, maintenant qu'on a parallélisé nos téléchargements et nos traitements, quelles améliorations sont possibles ? C'est là qu'il devient intéressant d' utiliser des outils de profiling , comme détaillé dans cet article.

Si on profile le code précédent (de la partie 3), on remarque que le Counter occupe une part significative du temps de traitement.

Note : La durée totale de 14.122s ne correspond pas exactement au temps précédent de 12.01s car, dans ce cas, nous avons profilé une seule exécution du code. De plus, le fait de profiler ajoute de l'overhead donc du temps supplémentaire (chose qui n'est pas faite lorsque nous mesurons uniquement le temps d'exécution).

Lorsque nous utilisons notre objet Counter pour compter et récupérer les pixels les plus courants, nous stockons les pixels sous forme de tuple de trois int, RGB . Ce qui n'est pas optimal. Counter fonctionne bien mieux avec des valeurs numériques et plus simples.

C'est pour cela que nous allons ajouter une étape de conversion pour transformer un tuple sous forme (R, G, B) en un entier qui représente cette même couleur.

Pour ce faire, nous allons créer une fonction rgb_to_int `` qui prend en paramètre un tuple d'int retournant un entier équivalent à ce tuple.

Pour ceux qui s'intéressent aux détails techniques de la conversion de RGB à un entier, voici une explication. Il est important de noter que, dans notre optimisation, nous remplaçons les tuples RGB dans notre Counter par de simples entiers.

4.1) Transformation d'un tuple RGB en entier

Laissez-moi vous montrer comment une petite modification peut engendrer une grande différence.

On va prendre l'exemple de la couleur rose représentée par le code RGB (255, 0, 255).

Conversion de RGB à Int :

RGB : (255, 0, 255)
En binaire, cela donne : R = 11111111, G = 00000000, B = 11111111

Ensuite, on décale ces valeurs :
    R décalé de 16 bits (<< 16) devient 111111110000000000000000
    G décalé de 8 bits (<< 8) reste 0000000000000000
    B reste inchangé : 11111111

On combine ces valeurs pour obtenir : 111111110000000011111111 en binaire
Ce qui donne en entier : 16711935

Pour simplifier, on prend chaque composante de couleur, et on la décale pour former un seul nombre. Ce nombre unique représente notre couleur originale. Cela ressemble à la manière dont on gère les permissions sur Linux : Read (4), Write (2), Execute (1). Lorsqu'on veut toutes les permissions, on utilise le chiffre 7, qui est la somme de 4, 2 et 1.

Le principe du décalage en binaire, comme dans l'opération 1 2 , signifie que l'on prend le nombre 1, le convertit en binaire (0001), et décale ses bits de deux places vers la gauche. Ainsi, 0001 devient 0100, ce qui équivaut à 4 en décimal.

Le code qui correspond à cette opération est celui-ci :

4.2) Transformation de l'entier vers le code RGB

Lorsque nous voulons afficher les résultats, nous cherchons à retrouver le code RGB initial. Donc, il nous faut un moyen d'inverser le calcul que nous avons fait. Voici comment cela fonctionne:

Le masquage binaire est une opération qui permet d'isoler certains bits dans un nombre binaire. Dans le cas de la fonction int_to_rgb , le masque 0xFF est utilisé pour extraire les 8 bits les plus bas d'un entier. Le masque 0xFF est de l'hexadecimal et est équivalent à 11111111 en binaire. Ce qui signifie qu'il conserve les 8 bits avec lesquels il est comparé et met tous les autres à zéro.

Entier : 16711935
Binaire : 111111110000000011111111

Extraction de Rouge (R) :
  Décalage : >> 16 donne 11111111
  Masque : 11111111 & 11111111 = 11111111
  Résultat : 255 (en décimal)

Extraction de Vert (G) :
  Décalage : >> 8 donne 0000000011111111
  Masque : 00000000 & 11111111 = 00000000
  Résultat : 0 (en décimal)

Extraction de Bleu (B) :
  Pas de décalage
  Masque : 11111111 & 11111111 = 11111111
  Résultat : 255 (en décimal)

RGB : (255, 0, 255)

Lorsque nous faisons du développement web, ou autre, nous ne sommes pas souvent confrontés à cette syntaxe. Aussi un peu de pratique peut être bénéfique. Le mieux est de démarrer un interpréteur Python et de faire quelques tests.

Le code représentant l'opération de transformation d'entier vers RGB est celui-ci :

Fin de la parenthèse.

Voyons le code complet.

Voici le résultat pour ce script :

v4: Mean = 7.80s, Stdev = 0.61s, Speedup = 7.58x

Wow, le temps est bien réduit rien qu'avec cette modification.

Je n'aurai pas pensé que le type de données utilisées par Counter pourrait avoir une influence aussi grande.

5. Traitement par batch

Nous l'avons évoqué précédemment, nous avons besoin de plusieurs processes afin de paralléliser les calculs, car sinon cela prendrait trop de temps sur un seul processeur.

Cependant, le fait de compter les pixels n'est pas si long que ça. Démarrer un nouveau process et faire transiter les data est coûteux.

Ne serait_il pas possible de faire quelque chose à ce niveau ?

Pourquoi ne pas traiter plusieurs images d'un coup, puis mettre à jour un Counter pour un batch d'images ?

La mécanique reste la même, nous spawnons toujours autant de processes (les Process ne sont créés qu'une fois et réutilisés grâce au ProcessPoolExecutor ), nous allons traiter plusieurs images d'un coup. Donc réduire le nombre de réutilisations de chaque process et aussi réduire le nombre de données qui doivent passer du process au main process pour avoir les résultats finaux.

Car au lieu d'envoyer 200 (nombre d'images) fois des Counter, nous allons en envoyer plus que 20 (pour des batchs de 10 images). Ce qui évite la procédure de pickling et unpickling qui consomme également du temps.

Voici les résultats pour cette version :

v5: Mean = 2.67s, Stdev = 0.03s, Speedup = 22.20x

2.67s pour télécharger et traiter les 200 images, contre 59s à la base, c'est pas trop mal.

Nous avons donc accompli encore un joli pas en avant.

Le choix du nombre 10 pour les batches est arbitraire. Il est conseillé d'expérimenter avec différentes tailles de batch pour trouver le nombre le plus optimal, en augmentant ou diminuant cette valeur.

Voici le profiling.

Comme précédemment, les résultats sont différents en raison de l'overhead du profiling. Nous pouvons donc voir qu'il y a du temps passé dans le multiprocessing et également que nous passons encore pas mal de temps dans le Counter.update.

Nous verrons si nous pouvons améliorer ces performances dans un prochain article !

Les résultats

Si on compare les résultats de toutes nos versions, nous obtenons ceci :

Results:
v1: Mean = 59.17s, Stdev = 9.09s, Speedup = 1.00x
v2: Mean = 38.85s, Stdev = 0.27s, Speedup = 1.52x
v3: Mean = 12.01s, Stdev = 0.68s, Speedup = 4.93x
v4: Mean = 7.80s, Stdev = 0.61s, Speedup = 7.58x
v5: Mean = 2.67s, Stdev = 0.03s, Speedup = 22.20x

Les prochaines étapes ?

Il existe d'autres optimisations que nous pourrions explorer.

Par exemple, envisager d'utiliser des bibliothèques comme Numpy ou Polars , qui exécutent du code en C et Rust respectivement. Ces outils sont spécialement optimisés pour le traitement efficace de données volumineuses.

Nous pourrions aussi choisir d'exécuter notre code sur une autre implémentation de Python que CPython (qui est l'implémentation standard de Python). Des alternatives comme PyPy ou IronPython peuvent offrir des avantages en terme de performances pour certains types de tâches.

Une autre stratégie consiste à écrire certaines parties critiques de notre code en C, Cython ou Rust.

Et bien sûr, il y a sûrement d'autres méthodes d'optimisation à découvrir et à expérimenter.

Mais ça, nous le garderons pour une prochaine fois !

Python est polyvalent, flexible et nous permet de réaliser beaucoup de choses.

Cependant, parfois notre code est lent et aurait bien besoin d'être optimisé !

Dans ce guide, nous allons voir des méthodes pour profiler les cas les plus fréquents dans le monde réel :

• Une fonction Python
• Un script Python
• Une API Flask FastAPI
• Une route Django

Le profiling est une étape essentielle à l'optimisation de vos performances.

Sans profiling vous risquez de faire des optimisations inutiles, voire dans le pire des cas, nuire aux performances.

Le code fourni a été pensé afin d'être réutilisable et adaptable à vos besoins.

Sans plus attendre, analysons notre script à profiler.

*Note : Il existe des dizaines de méthodes pour profiler et mesurer les performances : le module timeit , la librairie py-spy , la commande Linux **perf...*Ici, je ne vous parlerai que de ceux que je trouve les plus performants et qui apportent le plus d'informations avec le minimum d'efforts.

Notre point de départ

Prenons comme point de départ un script de base qui traite une liste de 446 901 villes , extraites d'un fichier texte nommé cities.txt.

Notre défi ! Compter les villes dont les noms contiennent plus de X voyelles.

Ce script, intentionnellement non optimisé, va nous servir de cobaye. Il illustre une situation courante en développement :

• on écrit d'abord un code qui fonctionne.
• on mesure les performances.
• on l'optimise pour améliorer ses performances si besoin.

Mais ici, nous irons plus loin.

Non seulement, nous profilerons ce script, mais également nous l'adapterons pour le profiler dans les divers environnements cités précédemment (script, API, Django ...).

Notre objectif : comprendre comment visualiser les problèmes de performances en fonction de la situation . Bien que nous ne réaliserons pas l'optimisation elle-même, cette analyse fournira un cadre solide afin d'effectuer vos propres améliorations et mesurer l'impact sur les performances.

Voici notre code :

1. Une fonction

Ici nous voulons analyser la fonction find_cities_with_vowel_count afin de mesurer le temps qu'elle prend, et les endroits chronophages.

1.1) Un décorateur pour mesurer le temps

Afin d'estimer le temps pris par la fonction, nous pouvons créer un décorateur que nous appliquerons sur les fonctions qui nous intéressent, et avoir une idée du temps d'execution. L'avantage est d'avoir un court overhead, donc de ne pas trop fausser les résultats.

Voici une implémentation possible de ce décorateur :

Ensuite, nous pouvons l'ajouter à notre fonction pour pouvoir mesurer le temps :

Lorsque nous exécutons notre programme normalement, nous avons ceci qui s'affiche dans la console :

92768
Elapsed time: 0.3522 seconds

Okay, donc cela traduit que dans notre liste, nous avons 92 768 villes ayant 5 ou plus de 5 voyelles. Et nous pouvons constater que notre script a pris 0.3522 secondes pour s'exécuter.

Mais, les indications sont trop maigres pour nous permettre de trouver les endroits chronophages.

1.2) Un décorateur pour profiler

Dans cet article, nous avons recours à cProfile , un deterministic profiler intégré à Python.

cProfile est un module de Python, donc nous pouvons l'utiliser directement dans notre script, nous pouvons donc réaliser un décorateur.

Un rapide rappel sur la manière de lire les résultats de cProfile:

• Nombre d'appels (ncalls) : cProfile affiche le nombre total d'appels pour chaque fonction sous la colonne 'ncalls'. Cela inclut les appels directs et récursifs.

• Appels récursifs (ncalls) : Les appels récursifs sont également inclus dans 'ncalls'. Les appels récursifs sont souvent indiqués sous une forme '3/1', où le premier nombre est le nombre total d'appels et le second le nombre d'appels récursifs distincts.

• Temps total par fonction (cumtime) : Sous la colonne 'cumtime', cProfile indique le temps cumulatif passé dans la fonction et toutes les fonctions qu'elle appelle.

• Temps propre par fonction (tottime) : Le temps propre, indiqué dans la colonne 'tottime', représente le temps passé uniquement dans la fonction elle-même, excluant le temps passé dans les fonctions appelées.

  Tiré de Les différents types de profilers

Voici un exemple :

Ce décorateur fonctionne sur le même principe que le précédent.

Il commence un profiling au début de l'exécution de la fonction, et arrête ce profiling aprés que la fonction ait terminé. Les résultats sont ensuite affichés en utilisant le module pstats.

Après avoir décoré notre fonction avec ce décorateur et exécuté notre code, nous observons plusieurs éléments clés :

Nous pouvons voir :

Le temps d'exécution passe de 0.3522 secondes à 2.10 secondes, soit presque un facteur de 6.

Bien que cet overhead soit important, il fournit des informations précieuses :

Par exemple, la méthode str.lower est appelée 19 002 850 fois, prenant 0.909 secondes -- presque la moitié de notre temps total . De plus, la fonction count_vowels est appelée 446 902 fois (une fois par ville) et prend 1.102 secondes.

Ces deux fonctions représentent donc la majorité du temps d'exécution.

Ces observations indiquent clairement que pour optimiser notre script, nous devons réduire le nombre d'appels à .lower(), et examiner de près le code de count_vowels.

2. Un script

Lorsqu'il s'agit de mesurer le temps d'exécution total d'un script Python, plusieurs méthodes sont à notre disposition.

2.1) Utiliser la command Linux "time"

La méthode la plus simple consiste à utiliser la commande Linux time. Cette approche offre un mesure rapide à mettre en place, avec un très faible overhead.

Avec time, nous obtenons des informations basiques, mais utiles. Par exemple, nous pouvons voir que le script prend 0.367 secondes pour s'exécuter, ce qui est similaire à ce que nous avons mesuré précédemment avec time.perf_counter.

De plus, l'indication de 99% d'utilisation du CPU suggère que notre programme consacre presque tout son temps à des opérations de calcul. Pour plus de détails sur la commande time, vous pouvez consulter l'article dédié aux différents types de profilers.

Bien que ces informations soient utiles, elles n'apportent pas suffisamment de détails pour une mettre en place des optimisations.

2.2) Utiliser cProfile en CLI

Pour obtenir des informations plus détaillées, nous pouvons utiliser cProfile en ligne de commande. Cette méthode permet de profiler le script et d'en examiner les résultats de manière approfondie. Pour ce faire, il suffit d'exécuter la commande suivante :

Si vous voulez visualiser les résultats d'une manière un peu plus friendly, vous pouvez utiliser une librairie comme SnakeViz :

>>> pip install snakeviz

>>> python -m cProfile -o result.cprof profile_script.py

>>> snakeviz result.cprof

2.3) Utiliser PyInstrument

Nous pouvons également utiliser un statistical profiler comme PyInstrumentpour mesurer le script en CLI.

Il est également possible d'avoir un rendu différent si on le souhaite, par exemple, en utilisant speedscope.

>>> pip install pyinstrument

>>> npm install -g speedscope

>>> pyinstrument -r speedscope -o profile.speedscope.json profile_script.py

>>> speedscope profile.speedscope.json

De la même manière que SnakeViz, c'est un rendu plus intéractif. Il est possible de naviguer dans les différentes vues afin de visualiser le déroulement de notre programme.

Nous pouvons filtrer, réorganiser, exporter, voir les call stacks. Bref, c'est un outil assez complet.

3. Une API

L'un des cas les plus courants est le profiling d'applications web.

Examinons trois scénarios fréquents : le profiling de routes dans Flask , FastAPI et Django.

Nous allons mettre en place des solutions génériques que vous pourrez réutiliser facilement.

3.1) Flask

Prenons l'exemple d'une application Flask basique.

Nous avons configuré un serveur Flask avec une route simple vers "/", qui exécute notre code et renvoie le résultat.

En utilisant Flask , il est possible d'executer du code juste avant qu'une requête HTTP ne soit traitée , et également après qu'elle ait été traitée.

Voyez-vous les possibilités ? 🧐

Finalement nous nous retrouvons à faire quasiment la même chose qu'avec le décorateur que l'on a vu plus haut !

Avant de rentrer dans notre route, nous démarrons le profiler et nous le stoppons une fois l'opération terminée.

Le véritable avantage ici, c'est la capacité de choisir quand profiler notre code. Comment ? Simplement en ajoutant un query parameter ?profile dans l'URL.

Cette approche est très pratique car elle ne nécessite aucun changement dans les routes existantes ou l'ajout de décorateurs supplémentaires.

Accès standard à l'application :

• URL : http://127.0.0.1:5000/
• Résultat : "OK", affichage normal sans profiling

Accès avec profiling activé :

• URL : http://127.0.0.1:5000/?profile
• Résultat : le résultat du profiling est généré et renvoyé

Vous pouvez évidemment modifier ce code pour utiliser d'autres types de profilers plutôt que PyInstrument.

3.2) FastAPI

De la même manière que Flask, nous allons utiliser le concept de middleware sur FastAPI.

C'est du code qui est executé pour chaque requête.

Nous allons vérifier s'il y a un paramètre"profile" dans l'URL. Si oui, nous renvoyons le résultat du profiling. Dans le cas contraire, nous renvoyons le résultat normal.

Et hop là :

Comme pour les autres cas, nous utilisons PyInstrument dans cet exemple, mais vous pouvez utiliser un autre profiler sans soucis.

3.3) Django

Si vous utilisez Django, l'intégration de PyInstrument pour le profiling requiert seulement quelques étapes simples :

1. Installation de PyInstrument : Commencez par installer PyInstrument dans votre projet.
2. Configuration du Middleware : Il suffit d'ajouter un middleware en modifiant la variable MIDDLEWARE dans vos paramètres Django.

Cette modification se résume à l'ajout d'une seule ligne dans la configuration.

Quand le middleware de PyInstrument est configuré, il suffit d'ajouter un query parameter "profile " à vos URL pour activer le profiling.

Voici comment cela fonctionne en pratique :

• URL Standard : Accéder à http://127.0.0.1:5000/example renverra le résultat normal
• URL avec Profiling : Accéder à http://127.0.0.1:5000/example?profile=1 les résultats du profiling seront renvoyés pour cette route.

Vous pouvez également ajouter de la configuration pour activer ou désactiver ce comportement en production.

Conclusion

Le profiling peut s'appliquer à presque tout en Python: scripts, fonctions, API, applications web.

Les exemples de code fournis sont conçus pour être directement réutilisables et adaptablesà différents types de profilers selon les besoins.

Les concepts de base sont similaires, rendant ces techniques transposables à d'autres frameworks web.

Liens utiles

• Les différents types de profiler
• Le deterministic profiler**cProfile** et**pstats**
• Le statistical profiler PyInstrument
• Outils de profiling pour Django :
  • Django Silk
  • Django Debug Toolbar
• Les outils de visualisation:
  • SnakeViz
  • Speedscope
  • gprof2dot

1. Les types de profilers

Il existe deux types de profiling couramment utilisés en Python : le Deterministic Profiling et le Statistical Profiling.
StuffAndCode Newsletter est une publication soutenue par ses lecteurs. Pour recevoir de nouveaux posts et soutenir mon travail, envisagez de devenir un abonné gratuit ou payant.

Note : Ici, on ne parle pas de profiling de mémoire mais uniquement de profiling de performances.

1.1) Deterministic Profilers

Les profilers déterministes, tels que cProfile, tracent et mesurent tous les appels de toutes les fonctions. Cette approche fournit des données détaillées sur chaque fonction appelée.

Nous pouvons avoir plusieurs informations grâce à ce type de profiling :

• Nombre d'appels (ncalls) : cProfile affiche le nombre total d'appels pour chaque fonction sous la colonne 'ncalls'. Cela inclut les appels directs et récursifs.
• Temps total par fonction (cumtime) : Sous la colonne 'cumtime', cProfile indique le temps cumulatif passé dans la fonction et toutes les fonctions qu'elle appelle.
• Temps propre par fonction (tottime) : Le temps propre, indiqué dans la colonne 'tottime', représente le temps passé uniquement dans la fonction elle-même, excluant le temps passé dans les fonctions appelées.
• Appels récursifs (ncalls) : Les appels récursifs sont également inclus dans 'ncalls'. Les appels récursifs sont souvent indiqués sous une forme '3/1', où le premier nombre est le nombre total d'appels et le second le nombre d'appels récursifs distincts.
• Ordre d'appel : L'ordre d'appel n'est pas directement visible dans les rapports standards de cProfile, mais des outils de visualisation tel que SnakeViz peuvent être utilisés pour voir l'ordre d'appel des fonctions.

Bien que le profiler puisse introduire un certain overhead, il reste utile pour l'identification des bottlenecks dans les programmes. Nous combinons souvent cProfile avec d'autres outils, comme des outils de visualisation pour interpréter les résultats si jamais le profiling est complexe.

L'overhead, quèsaco ?

L'overhead, en profiling, est le coût supplémentaire en termes de performance que votre programme doit supporter lorsqu'il est analysé par un profiler.

Prenons un exemple concret : si vous utilisez un profiler déterministe comme cProfile en Python, il va enregistrer des détails sur chaque appel de fonction et chaque opération dans votre programme.

Bien que cette information soit précieuse pour l'optimisation,le processus d'enregistrement lui-même nécessite des ressources supplémentaires - utilisation supplémentaire du processeur, consommation de mémoire, etc.> Cela signifie que votre programme, lorsqu'il est profilé, va probablement s'exécuter plus lentement et utiliser plus de ressources qu'en temps normal.> Ce ralentissement et cette consommation accrue sont ce qu'on appelle l'overhead . Il est important de tenir compte de cet overhead lors de l'analyse des résultats du profiler, car il peut fausser la perception des performances réelles du programme.> En bref, il est important de prendre en compte que l'overhead représente le coût en performance dû au processus de profiling lui-même.

1.2) Statistical Profilers

Les profilers statistiques, comme py-spy ou pyinstrument , adoptent une approche différente. Plutôt que d'enregistrer chaque appel de fonction, ils enregistrent la call stack à intervalles réguliers . Cette méthode génère moins d'overhead, ce qui est avantageux pour les applications en production où minimiser l'impact sur les performances est crucial.

La call stack est une structure de données qui permet de stocker des informations sur les instructions de notre programme qui sont en cours d'execution.

Plus d'informations ici

Bien que les profilers statistiques fournissent une vue d'ensemble utile, ils peuvent parfois manquer de certains détails fins que les profilers déterministes révèlent.

Ils sont particulièrement adaptés pour obtenir un aperçu global des performances d'une application, et pour identifier les zones où le temps est principalement consacré.

2. Les mesures de temps

2.1) CPU Time

Le CPU time correspond au temps durant lequel le CPU est occupé à exécuter du code. Par exemple, si vous avez une fonction qui envoie une requête à un site web et attend la réponse pour renvoyer le HTML, la majeure partie du temps sera passée en attente de la réponse du site, et non dans l'exécution de votre code proprement dit. Ainsi, le CPU time enregistré sera relativement faible.

2.2) Wall Clock Time

Le wall clock time, quant à lui, se mesure comme si on le faisait en regardant une montre. Il est particulièrement utile pour évaluer les performances d'applications qui interagissent beaucoup avec d'autres services, ou qui effectuent des appels à des API. Cette mesure permet de déterminer si la lenteur de l'application est due à votre code ou à l'attente de réponses externes.

Exemple : Mesurer le CPU time et le Wall clock time d'un script Python

Prenons un script Python basique, dummy.py, qui télécharge un gros fichier :

Nous pouvons mesurer le CPU time et le Wall clock time avec la commande Linux time.

Ici, real représente le temps total écoulé depuis le lancement jusqu'à la fin de l'exécution du script (Wall clock time).

User est le CPU time utilisé par le processus utilisateur (User CPU time).

Sys indique le CPU time utilisé par le système pour des tâches au niveau du kernel, telles que l'écriture de fichiers ou l'allocation de mémoire. Plus de détail sur cette réponse de StackOverflow :

Explication real, user, sys de la commande time

Dans cet exemple, la majorité du temps est consacrée à attendre la réponse du serveur(I/O), plutôt qu'à l'utilisation du CPU. Sur35 secondes environ d'exécution du script, seulement 2.6 secondes environ (user + sys) sont consacrées à des tâches CPU. Cela indique que pour optimiser ce code, il faudrait se concentrer principalement sur la partie réseau.

Les résultats

Nous allons profiler un script très simple afin de montrer les résultats que nous pouvons obtenir avec cProfile et pyinstrument , pour présenter un cas concret et expliquer comment interpréter les résultats.

Voici le code en question, une boucle avec des prints et un time.sleep.

Quelque chose de simple mais qui va pouvoir illustrer nos propos.

cProfile

Afin de profiler notre programme, nous pouvons utiliser la commande suivante :

python -m cProfile -s cumtime some_script.py

Nous pouvons voir que le script prend 1 seconde, donc ceci est un wall clock time ainsi que les endroits qui prennent le plus de temps. Par exemple, nous pouvons voir que time.sleep est la méthode qui prend le plus de temps (cf. la colonne tottime).

Aussi, nous pouvons observer que la fonction print a été appelée 10 fois. Nous pouvons changer l'ordre de cet output en fonction de ce que nous voulons examiner.

Nous pouvons également utiliser des outils de visualisation afin d'avoir un rendu plus graphique, mais ce n'est pas l'objet de cet article.

PyInstrument

Passons maintenant à pyinstrument. Pour l'installer, vous pouvez executer la commande :

pip install pyinstrument

et puis commencer le profiling :

pyinstrument some_script.py

Sur ce screenshot, nous pouvons constater plusieurs choses :

• tout d'abord, nous avons la durée qui est le wall clock time ainsi que le CPU time.
• Nous pouvons également remarquer que le CPU time est vraiment très court comparé au wall clock time, ce qui signifie que le CPU a été en attente pendant la quasi-totalité du programme.

Enfin, nous pouvons visualiser les méthodes qui prennent le plus de temps sous forme d'arbre, c'est assez pratique. Il peut y avoir plusieurs branches qui indiquent ce qui prend le plus de temps et permettent de savoir l'origine de l'appel.

Quizz Time

Je trouve qu'il est toujours pertinent de se remémorer ce qu'on vient de lire, pour vérifier si l'on a vraiment retenu quelque chose.

Voici quelques questions :

• Quels sont les différents types de profilers ?
• Quelles sont leurs différences ?
• Pouvez-vous nommer un profiler de chaque type ?
• Quelle est la différence entre wall clock time et CPU time ?

Si vous avez tout juste, vous avez compris l'essentiel de cet article, bien joué !

Si vous appréciez la newsletter StuffAndCode, vous pouvez vous inscrire afin de ne manquer aucun article !

🐍 Et recevez en PLUS, un article exclusif sur comment profiler n'importe quel type de code Python.

Abonnez-vous maintenant

StuffAndCode Newsletter est une publication soutenue par ses lecteurs. Pour recevoir de nouveaux posts et soutenir mon travail, envisagez de devenir un abonné gratuit ou payant.