J'ai mis un "debounce" sur les frappes au clavier (~250ms ?? de mémoire). Mais ce qu'il faut garder à l'esprit c'est que la partie client de l'éditeur n'est là que pour faire un "showroom" l'idée c'est vraiment de tester le code serveur websockets, et surtout, sous charge.
J'ai implémenté un petit client juste pour montrer comment le site ou n'importe quelle app tierce pourrait l'utiliser.
Pour les perfs, c'est assez lent pour le premier rendu juste après que le serveur ait été lancé. Et ensuite je trouve que ça répond plutôt vite. On peut le voir sur le bandeau en haut qui passe de orange (= j'envoie les données au serveur) à vert (= la preview est à jour) plutôt rapidement (parfois même plus rapide que le framerate du gifrecorder). Mais du coup pour le premier rendu j'ai du mal à piger ce qu'il faudrait faire car :
- tout est initialisé (Jython) au démarrage du serveur, pas au premier rendu
- même en faisant un pré-rendu d'un texte bidon au démarrage, ça reste lent au premier rendu…
Faudrait que j'investigue, c'est bizarre.
Au niveau charge pure et dure faut que je profile et SURTOUT que je teste sous charge (avec ~50 clients websockets qui demandent des rendus toutes les 250ms). J'ai remarqué un truc pendant le dev qui me fait dire qu'il y a des trucs pas nets : Vert.x a un mode "auto-redeploy" qui éteint et relance le serveur quand un fichier a changé. Je l'utilise généralement en développement et ça fonctionne très bien. Ici, au bout de quelques refresh, je prends des OutOfMemoryError (je pense que la stack Jython n'est pas "détruite" proprement) donc à regarder de près aussi.
Voilà 
