Etherpad-lite: Dégradation des performances sur la version 1.8.0 et les versions plus récentes

Cc @seballot

Nous avons une couverture de test pour cet afaik. Voir test du frontend de réactivité.

Le problème de la refusion est plus facile à réaliser lorsqu'il y a un grand nombre de nœuds.
Est-ce celui-là? https://github.com/ether/etherpad-lite/blob/develop/tests/frontend/specs/responsiveness.js
C'est commenté

Oh mon Dieu, je vais décommenter et m'assurer que nous avons une couverture de test fonctionnelle. Espérons que @seballot puisse trouver rapidement une solution performante :)

merci @JohnMcLear!

Non commenté, merci pour le rapport de bogue vraiment complet et bien conçu. Renversera @seballot : +1:

Pas encore entendu de @seballot malgré l'email / cc ici. Je suppose qu'il est en vacances et qu'il y arrivera dès que possible, mais si quelqu'un d'autre peut essayer pendant que nous attendons, ce serait idéal :)

Salut les gars ! merci pour ce rapport de bogue très clair @joassouza , et désolé pour le bogue

Je suis désolé d'être très concentré sur un autre projet en ce moment, j'essaierai de regarder de plus près ce billet la semaine prochaine. Mais si quelqu'un veut essayer de résoudre, soyez mon invité !!

@seballot juste une bosse pour cette semaine à venir pour vous assurer d'avoir un peu de temps dans votre emploi du temps pour jeter un coup d'œil à cela s'il vous plaît :) Merci!

Salut !

Je ne peux pas reproduire, j'ai fait un pad de 6000 lignes et cela fonctionne très bien

Testé sur Debian 9 -> Chromium 73 et Firefox 68

Pourquoi vos numéros de ligne semblent mauvais (le numéro 1 s'affiche correctement, puis à partir du numéro 2, il est trop grand et non aligné)?
Cela pourrait-il être un problème dans votre code local?
Peut-être que la dégradation des performances est uniquement sur Mac? quelqu'un d'autre peut-il essayer s'il vous plaît?

Je n'ai pas testé, mais je peux voir l'échec du test réactif de Firefox qui passait auparavant. Essayez le test réactif Firefox sans skin pour voir s'il a réussi?

test pass pour moi à la fois sur chrome et firefox

Oui, cela a juste passé pour moi aussi, donc je dois creuser plus profondément mais je me demande si cela passe pour nous parce que nous sommes sur des ordinateurs rapides (ish) et que les laboratoires de sauce jettent un peu de paysannerie pour gérer la tâche?

Je constate également un décalage nul sur FF sur Ubuntu

D'accord, changer amount en 1600000 (crée 8k lignes) rend le décalage perceptible pour moi.

Essayez de faire ça @seballot , tests/frontend/specs/responsiveness.js line 26

Cependant, je ne peux pas confirmer s'il s'agit d'un nouveau bogue, cela vaudrait la peine de vérifier 1.7.9 ou autre et de m'assurer que le comportement est réellement différent. Il doit y avoir une raison pour laquelle le test de réactivité se situait à environ 1 000 lignes.

Il est également intéressant de noter que l'expérience sur Firefox 52 est le problème, FF moderne semble bien? Le test de réactivité plante sur FF 52 mais ça va en 80. En fait ça plante le navigateur. - Alors j'imagine tester dans Firefox 52? Je teste sur SL maintenant.

Le test réactif échoue sur this.timeout n'est pas une erreur de fonction. https://github.com/ether/etherpad-lite/pull/4257/files

Juste pour donner plus de contexte. Les tests ont été réalisés sur Chrome sur MacOs. Nous pourrions reproduire la même erreur sur des machines très rapides comme i9, 64 Go de RAM.
@seballot pourriez-vous essayer de modifier au début du pad?
Je viens d'essayer une machine Windows utilisant également Chrome et j'ai le même délai.
https://video.etherpad.com/p/example_long_pad

J'ai testé Firefox comme un idiot, je vais tester Chrome maintenant.

Okay wow ouais c'est mauvais. J'ai changé le montant en 800000 et le décalage est horrible.

Je crois que le délai augmente si vous éditez au début du pad. Comme, dans la première ligne de celui-ci.

Je ne suis pas trop familier avec les outils Chrome Performance, mais c'est ce que je vois en essayant de modifier le pad responsiveness.js.

Remarquez que je n'ai pas tout le temps de mise en page comme vous?

J'ai essayé FF sur une machine Windows et j'ai le même délai. Utilisation de ce pad

https://video.etherpad.com/p/example_long_pad
A propos de la redistribution, cela dépend du CSS appliqué, du navigateur, du code js qui le déclenche, .... C'est pourquoi j'ai fait les tests sans plugin. Je dois vérifier le code du test de réactivité pour comprendre pourquoi dans ces tests, vous ne réalisez pas le retard.

Salut ! en effet avec 8K il commence à geler. Mais je suis passé à 1.7.5 et avec le pad de 8k ça gèle pareil (je dirais même que c'est pire!)

Quoi qu'il en soit, c'est un fait que etherpad devient lent lorsque les pads sont trop gros. Je ne pense pas que ce soit un bug critique, car les pads ne sont pas faits pour écrire des livres, et je pense que la plupart des gens les utilisent pour du texte court.

Mais oui, nous pourrions probablement nous améliorer. Mais je pense que ce sera un travail pénible :) De plus, je ne suis pas sûr que ce sera uniquement lié à la mise en page standard, car une spécificité est qu'etherpad utilise différents iframes, et nous devons donc toujours exécuter javascript pour aligner la mise en page entre eux (pour la hauteur de ligne par exemple)

J'essaierais de jeter un œil, mais je ne promets rien parce que
1- ça ne semble pas très drôle :)
2- Je ne pense pas que ce soit un bug critique

@JohnMcLear J'ai essayé de jeter un œil maintenant, mais je ne comprends pas, chaque changement que je fais à ace2_inner.js (même en supprimant tout le fichier) n'affecte pas mon instance locale, cela fonctionne toujours de la même manière. Qu'est-ce que je rate?

ace2_inner.js est demandé sans la chaîne de version atm, donc l'URL vers ace2_inner.js ne change pas et le cache de votre navigateur est utilisé. Lorsque vous définissez maxAge = 0 dans settings.json et / ou désactivez le cache du navigateur, il doit servir le nouveau fichier sans redémarrage.

Salut @ webzwo0i ! Merci pour ton aide ! Je me souviens enfin que je dois invalider moi-même le cache de ace2_inner car il est chargé dans l'iframe ...

(maxAge = 0 n'a eu aucun impact btw)

Un peu tard maintenant, regardera demain!

Une astuce consiste à utiliser l'onglet réseau ouvert car il désactive la mise en cache.

@joassouza pouvez-vous confirmer les découvertes de Sébastien?

OK fait ! en fait ce n'était pas très compliqué, grâce à @joassouza qui a fait tout le travail pour trouver à la fois le problème et la solution

et je confirme que le bogue n'est pas lié aux changements récents de l'interface utilisateur, il est là depuis longtemps je pense!

Je suppose que cela peut être fermé maintenant avec le correctif # 4267
Merci encore une fois @seballot