Added to the performance tab of the doc

docs/index.md

@@ -2278,7 +2278,64 @@ Voila. Ce fut une petite liste non exhaustive de quelques difficultés technique
 
 ----
 
-[A remplir à la fin du projet pour parler des différentes methodes d'optimisation]
+Ici je vais parler des techniques que j'ai utilisé pour réduire le temps de traitement de chaques images de 50 secondes à un peu moins de 3 sur le processeur de mon laptop. En effet, dans les premières version du projet, traiter l'intégralité d'une image pouvait prendre presque une minute.
+
+Ce qui est compliqué dans ce projet c'est qu'il y a un certain nombres de choses que je ne contrôle pas. En utilisant Tesseract, je me retrouve avec des incompressibles. En imaginant que l'OCR sur une image prenne 300ms, même si j'avais 180 threads capables de faire cette tâche en même temps, le temps de traitement sera toujours d'au moins 300ms. Créer une instance de Tesseract prend également du temps. Ma mission n'est donc pas d'arriver à des temps de quelques dixaines de milisecondes mais plutôt de rajouter le moins de temps possible pendant le traitement et de tenter de faire le plus du choses possible en paralelle.
+
+Voici la liste des choses qui prennent du temps :
+
+- Lancement du navigateur et navigation
+- Création des instances de Tesseract
+- Filtrage des images
+- OCR
+
+Ce sont les quatres gros postes qui coutent le plus cher en ressources.
+
+Mais par chance, deux de ces postes ne sont appelés qu'une seule fois au démarrage ce qui fait que ce n'est pas catastrophique si ils prennent du temps. Tandis que l'OCR et le filtrage est fait à chaque détection.
+
+Pour ce qui est du démarrage malheureusment on ne peut pas faire grand chose. Lancer le browser et naviguer à travers la F1TV prend du temps surtout si la connection du client est mauvaise. Pour certaines actions, j'ai fait un système qui essaie pendant 10 secondes de cliquer sur un bouton plutôt que d'attendre 10 secondes et cliquer pour tenter d'économiser un peu mais malheureusment, c'est lent et on ne peut pas y faire grand chose.
+
+Pour la génération des instances de Tesseract c'est un peu pareil mais pour d'autres raisons. Comme Tesseract n'est pas "Thread Safe" (Ce qui veut dire qu'il n'est pas paralellisable), si on veut faire plusieurs reconnaissances à la foix il faut plusieurs instances de Tesseract loadées en mémoire. J'ai donc décidé pour une question de simplicité et de performances de faire en sorte que chaque fenêtre de donnée ou "Window" aie sa propre instance de Tesseract.
+
+Vous qui lisez ces lignes êtes peut-être en train de vous dire "Oulala mais ca doit beaucoup de mémoire son truc la " et vous auriez parfaitement raison !
+
+!["Consommation de mémoire peu après avoir commencé la détection"](./Images/Screens/MemoryUtilisation.png)
+
+Ce programme consomme en effet une quantité absolument catastrophique de mémoire vive. Mais si je l'ai fait c'est pour une bonne raison. Cela prend juste beaucoup trop de temps de créer une nouvelle instance à chaque boucle de Tesseract et c'est encore plus long de faire toutes les opérations d'OCR les unes après les autres pour n'avoir qu'un seul Tessreact de loadé.
+
+On peut parfois arriver à des chiffres qui approchent les 4GB de ram ce qui est absolument RIDICULE. Cependant c'est un compromis que j'étais prêt à faire pour avoir une application qui soit plus rapide.
+
+Je suis absolument certain que cette solution et les autres solutions que j'ai trouvé pour ce projet ne sont pas les meilleures ou les plus efficaces. Mais ce sont les solutions que j'ai trouvé pour faire en sorte que le projet avance et fonctionne à peu près vite.
+
+Ensuite pour ce qui est de ce qui se passe à chaque boucle, la le mot magique c'est "Parallel". Le traitement de toutes les zones est fait en même temps.
+
+La structure du projet en zones, sous zones et fenêtres de données fait qu'il est assez facile de venir paralleliser le processus si on les implémente correctement.
+
+![Diagramme qui montre comment les zones et fenêtres intéragissent](./Images/Figma/ZonesStuctureDiagram.png)
+
+On peut voir sur ce diagramme que la zone principale demande à toutes les sous zones de décoder leur contenu. Ces dernières font l'exacte même chose avec les fenêtres de données qui retournent chacunes ce qu'elles contiennent après un coup d'OCR et ensuite les zones recombinent les informations et les envoient à la zone principale.
+
+Tout cela est très bien mais quel rapport avec la paralellisation ? Et bien comme chaque zone de pilote est indépendante, on peut tout simplement faire une boucle for parallelle qui appèle toutes les zones pilotes.
+
+On passe de 15 à 20 secondes de traitement à un peu plus de 3 juste avec cette technique. Alors ca n'était pas facile à implémenter car il a fallu programmer les zones de sorte à ce qu'elles soient toutes indépendantes les unes des autres. Mais une fois que le travail en amont a été effectué il est très simple de paralelliser.
+
+Les filtres fonctionnent de la même facon sauf que la on paralellise le traitement de chaque ligne dans une image. L'impact est moindre qu'avec les zones mais si on teste avec une machine assez puissante cela pourrait faire la différence.
+
+Seul soucis avec cette methode, cela feut dire que le processeur est particulièrement solicité '^^...
+
+!["Utilisation du processeur pendant le fonctionnement de l'application"](./Images/Screens/CPUUsage.png)
+
+Mon laptop ne possède malheureusement que six coeurs ce qui limite pas mal la puissance de la paralellisation. Mais je suis convaincu qu'avec un CPU avec plus de coeurs on pourrait arriver à d'encore meilleurs résultats.
+
+Mais cette utilisation du processeur a aussi un inconvénient... 
+
+!["Températures du laptop pendant le fonctionnement de l'application"](./Images/Photos/PCThermals.jpg);
+
+Donc si je veux commenter la F1 avec cet outil, note à moi même, je ne dois pas utiliser le laptop si je ne veux pas me cramer les doigts.
+
+Si je pouvais utiliser le GPU pour accèlérer le processus on pourrait peut-être avoir de meilleurs résultats mais de ce que j'ai pu lire, l'OCR n'est pas spécialement un bon use case pour les GPU.
+
+Pour conclure, je dirais que ce projet est loin d'être un exemple de performances et clairement il y a des choix discutables qui ont été faits et d'une manière générale si je devais refaire tout le projet avec la performance en premier objectif, j'aurais sûrement fait différemment. Maintenant avec le temps que j'ai eu je suis déja content d'avoir pu faire quelque chose qui fonctionne et qui ne prenne pas une minute à traiter une image.
 
 ## Ethique du projet