Etherpad-lite: Снижение производительности на 1.8.0 и более новых версиях

Копия @seballot

У нас есть тестовое покрытие для этого afaik. См. Тест на отзывчивость интерфейса.

Проблему перекомпоновки легче реализовать при большом количестве узлов.
Это один? https://github.com/ether/etherpad-lite/blob/develop/tests/frontend/specs/responsiveness.js
Это прокомментировано

О боже, я раскомментирую и обеспечу рабочее покрытие тестами. Надеюсь, @seballot поспешно найдет исправление :)

спасибо @JohnMcLear!

Без комментариев, спасибо за действительно подробный и хорошо составленный отчет об ошибке. Снова ударит @seballot : +1:

Еще не получил ответа от копию здесь. Я предполагаю, что он в отпуске и займется этим как можно скорее, но если кто-то еще может нанести удар, пока мы ждем, это было бы идеально :)

Привет, ребята ! спасибо за очень четкий отчет об ошибке

Извините, я сейчас очень сосредоточен на другом проекте, я постараюсь внимательно изучить этот билет на следующей неделе. Но если кто-то хочет попробовать решить, будь моим гостем !!

@seballot просто

Привет !

Я не могу воспроизвести, я сделал блокнот длиной 6000 строк, и он отлично работает

Проверено на Debian 9 -> Chromium 73 и Firefox 68

Почему номера ваших строк выглядят плохо (номер 1 отображается нормально, затем номер 2 слишком большой и не выровнен)?
Может быть проблема в вашем местном кодексе?
Может, падение производительности только на Mac? может кто-нибудь еще попробуйте?

Не тестировал, но вижу, что тест реагирования Firefox не прошел, который раньше проходил. Попробовать тест на отзывчивость Firefox без установленного скина, чтобы убедиться, что он прошел?

тест прошел для меня как на Chrome, так и на Firefox

Да, это тоже прошло для меня, так что мне нужно копать глубже, но мне интересно, пройдет ли это для нас, потому что мы на быстрых (иш) компьютерах, а лаборатории соуса подбрасывают некоторых крестьянских виртуальных машин, чтобы справиться с задачей?

Я также испытываю нулевую задержку на ff на ubuntu

Хорошо, поэтому изменение amount на 1600000 (создает 8k строк) делает отставание заметным для меня.

Попробуйте сделать это @seballot , tests/frontend/specs/responsiveness.js line 26

Я не могу подтвердить, является ли это новой ошибкой, стоит проверить 1.7.9 или что-то еще и убедиться, что поведение действительно другое. Должна быть причина, по которой тест на отзывчивость был примерно на отметке в 1 тыс. Строк.

Также стоит отметить, что проблема в Firefox 52, современный FF кажется нормальным? Тест на отзывчивость вылетает на FF 52, но нормально на 80. На самом деле это вызывает сбой браузера. - Так что, я думаю, тест в Firefox 52? Сейчас тестирую на SL.

Адаптивный тест не проходит на this.timeout не является ошибкой функции. https://github.com/ether/etherpad-lite/pull/4257/files

Просто чтобы дать больше контекста. Тесты проводились в Chrome на MacOs. Мы могли воспроизвести ту же ошибку на действительно быстрых машинах, таких как i9, 64 ГБ ОЗУ.
@seballot не могли бы вы попробовать отредактировать в начале блокнота?
Я только что пробовал использовать Chrome на машине с Windows, и у меня такая же задержка.
https://video.etherpad.com/p/example_long_pad

Тестировал Firefox как идиот, сейчас протестирую Chrome.

Ладно, да, это плохо. Я изменил сумму на 800000 и отставание ужасно.

Я считаю, что задержка увеличивается, если вы редактируете в начале пэда. Мол, в первой строке.

Я не слишком хорошо знаком с инструментами Chrome Performance, но именно это я вижу, пытаясь отредактировать панель responseiveness.js.

Обратите внимание, что я не получаю все время верстки, как вы?

Я пробовал использовать FF на машине с Windows, и у меня такая же задержка. Используя эту площадку

https://video.etherpad.com/p/example_long_pad
Что касается перекомпоновки, это зависит от того, какой CSS применяется, браузер, js-код, триггеры, .... Вот почему я провел тесты без какого-либо плагина. Мне нужно проверить код теста на отзывчивость, чтобы понять, почему в этих тестах вы, ребята, не понимаете задержки.

Привет ! действительно с 8К начинает мерзнуть. Но я перешел на 1.7.5 и с падом 8к он так же зависает (я бы даже сказал хуже!)

В любом случае, это факт, что etherpad тормозит, когда пэды слишком большие. Я не считаю это серьезной ошибкой, потому что блокноты не предназначены для написания книг, и я думаю, что большинство людей используют их для коротких текстов.

Но да, наверное, мы могли бы улучшить. Но я чувствую, что это будет болезненная работа :) Также я не уверен, что это будет связано только со стандартным мусором макета, потому что одна особенность заключается в том, что etherpad использует разные фреймы, и поэтому нам всегда нужно запускать javascript для выравнивания макета между собой (например, для высоты строки)

Я бы попробовал посмотреть, но ничего не обещаю, потому что
1- вроде не очень смешно :)
2- Я не считаю, что это критическая ошибка

@JohnMcLear Я попытался взглянуть сейчас, но не понимаю, каждое изменение, которое я делаю в ace2_inner.js (даже удаление всего файла), не влияет на мой локальный экземпляр, он по-прежнему работает так же. Что мне не хватает?

ace2_inner.js запрашивается без строки версии atm, поэтому URL-адрес ace2_inner.js не изменяется, и используется кеш вашего браузера. Когда вы устанавливаете maxAge = 0 в settings.json и / или отключаете кеш браузера, он должен обслуживать новый файл без перезапуска.

Привет @ webzwo0i ! спасибо за помощь! Наконец я вспомнил, что мне нужно аннулировать кеш ace2_inner, потому что он загружен в iframe ...

(maxAge = 0 кстати не повлиял)

Немного поздно сейчас, посмотрю завтра!

Один из приемов - использовать открытую вкладку сети, поскольку она отключает кеширование.

@joassouza, можешь подтвердить выводы Себастьяна?

Готово ! на самом деле это было не очень сложно, благодаря @joassouza, который сделал всю работу по поиску проблемы и решения

и я подтверждаю, что ошибка не связана с недавними изменениями пользовательского интерфейса, я думаю, она существует уже давно!

Думаю, теперь это можно закрыть с помощью исправления # 4267
Еще раз спасибо @seballot