Beschreibe den Fehler
Leistungseinbußen wurden in Version 1.8.0 eingeführt und können auch in neueren Versionen repliziert werden
Reproduzieren
Schritte zum Reproduzieren des Verhaltens:
Erwartetes Verhalten
Die Erstellung der neuen Zeile durch Drücken der EINGABETASTE sollte viel schneller erfolgen. Als Basis können wir die Version 1.7.5 verwenden.
Screenshots
Dies ist der Code, von dem ich annehme, dass er die Höhe des Iframes "ace2_inner" in Versionen älter als 1.8.0 geändert hat
https://github.com/ether/etherpad-lite/blob/1.7.5/src/static/js/ace2_inner.js#L4817
Wie der Screenshot zeigt, ist im iframe kein Höhenstil definiert. Seine Größe wird durch die Größe von definiert
#sidediv
Kinder. Dies ist möglich, weil es Flexbox verwendet.
https://youtu.be/LpthRFAH3GM
Bitte versuchen Sie zu hören, wenn ich tippe
Desktop (bitte vervollständigen Sie die folgenden Informationen):
Smartphone (bitte vervollständigen Sie die folgenden Informationen):
Ich habe auf keinem Smartphone getestet
Zusätzlicher Kontext
Das Hauptproblem ist auf die Kosten des Reflow zurückzuführen (siehe nächste Sitzung). Dies bedeutet, dass bei komplexeren CSS-Regeln die Verzögerung zunimmt.
Wenn wir #sidediv
auf display:none
, tritt diese Verzögerung nicht mehr auf, aber wir verursachen ein Problem mit der Größe des "ace2_inner", wie hier geschrieben https://github.com/ether/ etherpad-lite / blob / development / src / static / css / iframe_editor.css # L125
Auf beiden Versionen laufe ich ohne Plugin.
Die Renderzeit hat sich stark erhöht.
_sehen Sie, wie lange die Operation "Layout" dauert_
Cc @seballot
Wir haben Testberichterstattung für diesen Afaik. Siehe Reaktionsfähigkeits-Frontend-Test.
Das Problem des Reflow ist bei einer großen Anzahl von Knoten leichter zu erkennen.
Ist das einer? https://github.com/ether/etherpad-lite/blob/develop/tests/frontend/specs/responsiveness.js
Es ist kommentiert
Oh Mann, ich werde auskommentieren und sicherstellen, dass wir eine funktionierende Testabdeckung haben. Hoffentlich kann @seballot schnell einen performanten Fix finden :)
danke @JohnMcLear!
Unkommentiert, danke für den wirklich gründlichen und gut zusammengestellten Fehlerbericht. Wird @seballot erneut stoßen: +1:
Noch nicht von @seballot gehört, trotz E-Mail /
Hallo Leute ! Vielen Dank für diesen sehr klaren Fehlerbericht
Es tut mir leid, dass ich mich gerade sehr auf andere Projekte konzentriere. Ich werde versuchen, mir dieses Ticket nächste Woche genauer anzusehen. Aber wenn jemand versuchen will zu lösen, sei mein Gast !!
@seballot nur eine Beule für die kommende Woche, um sicherzustellen, dass Sie etwas Zeit in Ihrem Zeitplan haben, um sich das bitte anzusehen :) Danke!
Hallo !
Ich kann nicht reproduzieren, ich habe ein 6000 Zeilen langes Pad gemacht und es funktioniert gut
Getestet auf Debian 9 -> Chromium 73 & Firefox 68
Warum sehen Ihre Zeilennummern schlecht aus (Nummer 1 wird in Ordnung angezeigt, von Nummer 2 ist sie zu groß und nicht ausgerichtet)?
Könnte es ein Problem in Ihrem lokalen Code sein?
Vielleicht ist der Leistungsabfall nur auf dem Mac? kann jemand anderes es bitte versuchen?
Ich habe noch nicht getestet, kann aber feststellen, dass der Firefox-Reaktionstest fehlschlägt, der früher bestanden wurde. Versuchen Sie den Firefox-Reaktionstest mit No-Skin-Set, um festzustellen, ob er bestanden wurde.
Test bestanden für mich sowohl auf Chrom als auch auf Firefox
Ja, es ist auch nur für mich vorbei, also muss ich tiefer graben, aber ich frage mich, ob es für uns vorbei ist, weil wir auf schnellen (ish) PCs sind und Saucenlabors einige Bauern vm aufwirft, um die Aufgabe zu erledigen?
Ich erlebe auch keine Verzögerung bei ff auf Ubuntu
Okay, wenn ich amount
in 1600000
ändere (erstellt 8.000 Zeilen), macht sich die Verzögerung für mich bemerkbar.
Versuchen Sie das @seballot , tests/frontend/specs/responsiveness.js
line 26
Ich kann jedoch nicht bestätigen, ob dies ein neuer Fehler ist. Es lohnt sich, 1.7.9 oder was auch immer zu überprüfen und sicherzustellen, dass das Verhalten tatsächlich anders ist. Es muss einen Grund geben, warum der Test auf Reaktionsfähigkeit bei etwa 1 km Linien lag.
Es ist auch erwähnenswert, dass die Erfahrung mit Firefox 52 das Problem ist, moderne FF scheint in Ordnung zu sein? Der Reaktionstest stürzt auf FF 52 ab, ist aber in 80 in Ordnung.
Der reaktionsschnelle Test schlägt bei this.timeout
fehl. https://github.com/ether/etherpad-lite/pull/4257/files
Nur um mehr Kontext zu geben. Die Tests wurden auf Chrome unter MacOs durchgeführt. Wir konnten den gleichen Fehler auf sehr schnellen Maschinen wie i9, 64 GB RAM reproduzieren.
@seballot könntest du versuchen, am Anfang des Pads zu bearbeiten?
Ich habe gerade einen Windows-Computer mit Chrome ausprobiert und habe die gleiche Verzögerung.
https://video.etherpad.com/p/example_long_pad
Ich habe Firefox wie einen Idioten getestet und werde jetzt Chrome testen.
Okay wow ja das ist schlecht. Ich habe den Betrag in 800000
geändert und die Verzögerung ist schrecklich.
Ich glaube, die Verzögerung nimmt zu, wenn Sie am Anfang des Pads bearbeiten. Wie in der ersten Zeile.
Ich bin mit den Chrome Performance-Tools nicht allzu vertraut, aber das sehe ich, wenn ich versuche, das Pad responsiveness.js zu bearbeiten.
Beachten Sie, dass ich nicht die gesamte Layoutzeit wie Sie bekomme?
Ich habe FF auf einem Windows-Computer ausprobiert und habe die gleiche Verzögerung. Verwenden dieses Pads
https://video.etherpad.com/p/example_long_pad
Über den Reflow hängt es ab, welches CSS angewendet wird, Browser, js Code die Auslöser, .... Deshalb habe ich die Tests ohne Plugin durchgeführt. Ich muss den Code des Reaktionstests überprüfen, um zu verstehen, warum ihr in diesen Tests die Verzögerung nicht erkennt.
Hallo ! tatsächlich fängt es mit 8K an zu frieren. Aber ich habe auf 1.7.5 umgestellt und mit dem Pad von 8k friert es gleich ein (ich würde es sogar als das Schlimmste bezeichnen!)
Wie auch immer, es ist eine Tatsache, dass das Etherpad langsam wird, wenn die Pads zu groß sind. Ich glaube nicht, dass es ein kritischer Fehler ist, da der Block nicht zum Schreiben von Büchern gedacht ist, und ich denke, die meisten Leute verwenden ihn für kurzen Text.
Aber ja, wahrscheinlich könnten wir uns verbessern. Aber ich denke, es wird eine schmerzhafte Aufgabe sein :) Ich bin mir auch nicht sicher, ob es nur mit Standard-Layout-Papierkorb zu tun hat, da eine Besonderheit darin besteht, dass Etherpad unterschiedliche Iframes verwendet und wir daher immer Javascript ausführen müssen, um das Layout auszurichten untereinander (zum Beispiel für die Linienhöhe)
Ich würde versuchen, einen Blick darauf zu werfen, aber ich verspreche nichts, weil
1- es scheint nicht sehr lustig :)
2- Ich glaube nicht, dass es ein kritischer Fehler ist
@JohnMcLear Ich habe versucht, jetzt einen Blick darauf zu werfen, aber ich verstehe nicht, dass jede Änderung, die ich an ace2_inner.js
vornehme (sogar das Löschen der gesamten Datei), meine lokale Instanz nicht beeinflusst, sie funktioniert immer noch genauso. Was vermisse ich?
ace2_inner.js wird ohne Versionszeichenfolge atm angefordert, sodass sich die URL zu ace2_inner.js nicht ändert und Ihr Browser-Cache verwendet wird. Wenn Sie in settings.json maxAge = 0 setzen und / oder den Browser-Cache deaktivieren, sollte die neue Datei ohne Neustart bereitgestellt werden.
Hi @ webzwo0i ! Danke für deine Hilfe ! Ich erinnere mich endlich, dass ich den Cache von ace2_inner ungültig machen muss, weil er in den Iframe geladen ist ...
(maxAge = 0 hatte übrigens keinen Einfluss)
Ein bisschen spät jetzt, wird morgen schauen!
Ein Trick besteht darin, die geöffnete Registerkarte "Netzwerk" zu verwenden, um das Caching zu deaktivieren.
@joassouza kannst du Sebastians Ergebnisse bestätigen?
OK, fertig ! Eigentlich war es nicht sehr kompliziert, dank @joassouza, der die ganze Arbeit gemacht hat, um sowohl das Problem als auch die Lösung zu finden
und ich bestätige, dass der Fehler nicht mit den letzten Änderungen an der Benutzeroberfläche zusammenhängt, ich denke, er ist schon lange da!
Ich denke, dies kann jetzt mit dem Fix # 4267 geschlossen werden
Nochmals vielen Dank
Hilfreichster Kommentar
Hallo Leute ! Vielen Dank für diesen sehr klaren Fehlerbericht
Es tut mir leid, dass ich mich gerade sehr auf andere Projekte konzentriere. Ich werde versuchen, mir dieses Ticket nächste Woche genauer anzusehen. Aber wenn jemand versuchen will zu lösen, sei mein Gast !!