Pourquoi Monosnap est devenu si lent — et la solution

La taxe Electron, aggravée

Monosnap n'’a pas commencé comme une application Electron. Au début de son existence, une grande partie du code de capture et d'édition était natif. Au fil du temps, les composants de l'interface utilisateur ont été reconstruits sur un moteur de rendu Chromium — ce qui a facilité leur itération mais a ajouté un coût de démarrage important et permanent.

Electron ne’devient pas plus léger avec le temps. Chaque année, Chromium ajoute des fonctionnalités, livrant plus de code, une base de mémoire plus importante et une initialisation plus complexe. Une application qui était acceptable à 60 Mo en 2019 est maintenant un minimum de 180 Mo au lancement, et cela ne fait qu'augmenter. C'’est avant de considérer la fuite de mémoire que nous avons abordée sur la page de fuite de mémoire.

Lorsque vous appuyez sur Ctrl+Alt+5, Monosnap doit préchauffer un moteur de rendu Chromium pour afficher la superposition de capture. Sur une application froide, cela’prend plusieurs centaines de millisecondes. Sur une application "chaude" qui a déjà consommé des centaines de mégaoctets, cela’prend plus de temps. À la cinquième heure d'une journée de travail, l'incrustation s'affiche suffisamment lentement pour que les utilisateurs puissent percevoir une différence.

L'éditeur d'annotation est le pire coupable

La fenêtre de l'éditeur post-capture est presque entièrement une webview Chromium. Lorsque vous déposez une flèche ou dessinez un rectangle, l'outil envoie des événements via Electron’la limite IPC vers le processus natif et inversement. Cet aller-retour est rapide sur un processus frais et notablement lent une fois que le processus est chargé.

Pour les utilisateurs effectuant des annotations intensives — rapports de bugs, tutoriels, documentation — cela s'accumule. Dix minutes d'annotation donnent l'impression d'en faire vingt.

Maxisnap : pas d'Electron, pas de surcoût

Maxisnap’l'éditeur est une fenêtre native PyQt6. Le canevas d'annotation utilise QPainter directement sur un QPixmap.’il n'y a pas de webview, pas de limite IPC entre la logique de l'outil et la surface de rendu. Lorsque vous déposez une flèche, elle apparaît lors du prochain cycle de peinture. Il n'y a pas d'aller-retour.

Le démarrage à froid depuis la barre d'état système jusqu'à la capture est d'environ une seconde sur une machine typique. La capture vers l'éditeur prend moins de 200 ms. Ces chiffres restent les mêmes à la 1ère heure, la 4ème heure, la 8ème heure et la 72ème heure. L'application ne’se dégrade pas avec le temps car il’n'y a rien à accumuler.