Spyder: Spyder 4.0.0 невыносимо медленный при добавлении или удалении строк

Созданный на 9 дек. 2019  ·  30Комментарии  ·  Источник: spyder-ide/spyder

описание проблемы

Spyder работает очень-очень медленно каждый раз, когда я добавляю (с помощью Enter) или удаляю (с помощью сочетания клавиш Ctrl + D) строки в редакторе. На каждую строку в среднем уходит около секунды. При удерживании строчные команды будут буферизироваться, а затем они будут добавляться или удаляться с задержкой, может быть, две секунды на строку.

Та же проблема после spyder --reset. Также пробовал переключать автозаполнение. Это происходило с момента появления бета-версии / релиз-кандидата, и я не использовал его из-за этого. Для меня Spyder сейчас непригоден для использования.

Какие шаги воспроизводят проблему?

  1. Нажмите Enter или Ctrl + D

Каков ожидаемый результат? Что ты видишь вместо этого?

Я ожидаю, что это займет не так много времени, как старые версии.

Версии

  • Версия Spyder: 4.0.0
  • Версия Python: 3.7.5
  • Версия Qt: 5.9.6
  • Версия PyQt: 5.9.2
  • Название / версия операционной системы: Win 10

Зависимости

cloudpickle> = 0.5.0: 1.2.2 (ОК)
пигменты> = 2.0: 2.5.2 (ОК)
qtconsole> = 4.6.0: 4.6.0 (ОК)
nbconvert> = 4.0: 5.6.1 (ОК)
сфинкс> = 0.6.6: 2.2.2 (ОК)
pylint> = 0,25: 2,4,4 (ОК)
psutil> = 0.3: 5.6.7 (ОК)
qtawesome> = 0.5.7: 0.6.0 (ОК)
qtpy> = 1.5.0: 1.9.0 (ОК)
pickleshare> = 0,4: 0,7,5 (ОК)
zmq> = 17: 18.1.0 (ОК)
chardet> = 2.0.0: 3.0.4 (ОК)
numpydoc> = 0.6.0: 0.9.1 (ОК)
spyder_kernels> = 1.8.1; <2.0.0: 1.8.1 (ОК)
qdarkstyle> = 2.7: 2.7 (ОК)
atomicwrites> = 1.2.0: 1.3.0 (ОК)
diff_match_patch> = 20181111: 20181111 (ОК)
intervaltree: Нет (ОК)
сторожевой таймер: Нет (ОК)
брелок: Нет (ОК)
pexpect> = 4.4.0: 4.7.0 (ОК)
прыщ: Нет (ОК)
sympy> = 0,7.3: 1,4 (ОК)
cython> = 0,21: 0,29,14 (ОК)
IPython> = 4.0: 7.10.1 (ОК)
matplotlib> = 2.0.0: 3.1.1 (ОК)
панды> = 0.13.1: 0.25.3 (ОК)
numpy> = 1.7: 1.17.4 (ОК)
scipy> = 0.17.0: 1.3.1 (ОК)
пилс> = 0,31,2; <0,32,0: 0,31,2 (ОК)
rtree> = 0.8.3: 0.8.3 (ОК)

Editor Bug

Самый полезный комментарий

@bcolsen В дополнение к обновлению только текущего файла, он также не должен обновляться, если проводник структуры даже не отображается (как сейчас подтверждают мои испытания).

Все 30 Комментарий

@gabrielclow , твоего описания мало. Пожалуйста, разместите:

  1. Какие файлы вы редактируете (Python или другие)?
  2. Сколько строк у вас в файле?
  3. Включены ли у вас такие вещи, как "Направляющие отступа"?

Наконец, опубликуйте видео (анимированный gif с Licecap), чтобы увидеть, о чем вы в точности говорите.

@gabrielclow , твоего описания мало. Пожалуйста, разместите:

  1. Какие файлы вы редактируете (Python или другие)?
  2. Сколько строк у вас в файле?
  3. Включены ли у вас такие вещи, как "Направляющие отступа"?

Наконец, опубликуйте видео (анимированный gif с Licecap), чтобы увидеть, о чем вы в точности говорите.

  1. Я редактирую только файлы .py
  2. Не похоже, что это зависит от количества строк. Встречается в маленьких файлах с 50 строками до больших файлов с 5k строками.
  3. Я использую только автозаполнение (конфиг на скриншоте). Остальное отключено (без линтинга, без линтинга стилей кода, без линтинга строк документации, без направляющих для отступов). У меня нет настроек других языков, и я также пробовал включать и выключать Kite.

autocomplete

На гифке я удерживаю Enter, жду, пока будут созданы новые строки, а затем удерживаю Ctrl + Z, чтобы удалить их (тот же эффект, что и Ctrl + D, поэтому я предполагаю, что это также не имеет ничего общего с ярлык). Затем Spyder останавливается и добавляет или удаляет строки очень медленно, вместо того, чтобы делать это плавно:

stopwatch

обновление : видимо, если закрыть какие-то файлы, то замедление будет менее заметно!
обновление 2 : также, количество замедления, по-видимому, связано с количеством открытых файлов + количеством строк в каждом файле, но это происходит независимо от того, какой из них выбран в данный момент. Если я оставлю только несколько файлов меньшего размера, а остальные закрою, все будет намного плавнее
обновление 3 : если я удерживаю слишком долго или нажимаю слишком быстро, Spyder может даже зависнуть на некоторое время

Кроме того, количество замедлений очевидно связано с количеством открытых файлов.

Сколько файлов вы открыли, когда увидели самое сильное замедление?

Кроме того, количество замедлений очевидно связано с количеством открытых файлов.

Сколько файлов вы открыли, когда увидели самое сильное замедление?

Я в основном работаю с открытыми 6-8 файлами. Обычно около двух из них больше (4-5 тыс. Строк), а остальные - файлы меньшего размера со 100-500 строками.

@ CAM-Gerlach, вы видели что-то подобное раньше?

Если я могу прокомментировать это, у меня такая же проблема, из-за которой я фактически удалил Spyder 4 и вернулся к Spyder 3.3.6.
У меня включены только те настройки, которые включены в Spyder 3, поэтому проверка PEP8; автозавершение кода и детализация включены; но без проверки строки документации; фрагменты кода; описания наведения; воздушный змей; и т.п.
Замедление показано в GIF -

Когда я создаю большие пакеты, для меня нередко открываются одновременно 30-50 файлов Python, некоторые из которых могут легко содержать более 3 тыс. Строк кода (у меня они были открыты, когда я заметил значительное замедление).
Поскольку большую часть времени я использую 3 монитора одновременно для редактирования своих скриптов, которые могут содержать максимум 8 панелей, и мне нужно часто переключаться между файлами, закрытие большинства этих файлов для меня не сработает.

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

Есть ли случайно сценарий, который запускается во всех строках во всех открытых файлах при каждом изменении файла?
Это объяснило бы, почему замедление, похоже, увеличивается вместе с общим количеством строк во всех открытых файлах, и почему оно не зависит от редактируемого файла.

Я могу подтвердить эту ошибку. На моем компьютере это не так уж плохо (особо не замечал до сих пор), но добавление / удаление строки происходит намного медленнее, чем добавление текста. Проблема с вводом действительно заметна, если зажать.

@bcolsen , как это воспроизвести?

Открываю около 40 файлов и, кажется, очень хорошо тормозит. Похоже, что в docdidchange может быть что-то, что проверяет все файлы, а не только активный. Может, планировщик.

@ ccordoba12 Насколько я могу судить, это поведение в основном такое же, как # 8864, и, конечно же, я могу воспроизвести его с чистыми настройками в Spyder 4 final, открыв только mainwindow.py пока включены направляющие отступа ( разделение окон увеличивает задержку вдвое и более). Удаление строк имеет такую ​​же большую задержку (точно так же, как описано здесь; с задержкой ~ 1 с и задержкой повторения ~ 1 с на умеренно мощной машине и масштабируется пропорционально длине файла и количеству открытых разделенных панелей), что и другие вещи, которые я тестировал там (перемещение строк, дублирование строк и т.д.), и я могу подтвердить, что это все еще происходит на Spyder 4 final только с временным файлом и mainwindow.py открытым с чистыми настройками.

Тем не менее, я думал, что направляющие отступа не были включены по умолчанию, и на самом деле они, кажется, не включаются после того, как я сбросил настройки, но я не могу воспроизвести хоть какое-то время задержки с любым другим параметром (код реального времени анализ, завершение OTF, подчеркивание ошибок и предупреждений, отображение пробелов и т. д.); хотя, когда все они включены, сохраняются направляющие отступа, это немного отстает.

Есть ли случайно сценарий, который запускается во всех строках во всех открытых файлах при каждом изменении файла?

LSP вызывается, и я изначально думал, что это было так, но на основе его поведения с разделенными панелями, определенными отображаемыми элементами, но не другими и т.д. площадь и т. д.). Но это намного выше моей зарплаты.

@ ccordoba12 Насколько я могу судить, это поведение в основном такое же, как # 8864, и, конечно же, я могу воспроизвести его с чистыми настройками в Spyder 4 final, открыв только mainwindow.py пока включены направляющие отступа ( разделение окон увеличивает задержку вдвое и более).

Если я также включаю направляющие отступа вместе с открытыми 50 файлами и 8 разделенными панелями (именно так я обычно редактирую свои файлы), задержка увеличивается до 6–10 секунд на новую строку.
Я использую компьютер для игр высокого класса, так что это не совсем из-за мощности машины.

Мы с @dalthviz безуспешно пытались воспроизвести # 8864. Сожалею, но пока мы не сможем воспроизвести это, мы ничего не можем с этим поделать.

Открываю около 40 файлов и, кажется, очень хорошо тормозит. Похоже, что в docdidchange может быть что-то, что проверяет все файлы, а не только активный. Может, планировщик.

Хорошо, это хорошее начало. Мы проверим это.

@ ccordoba12 Я выяснил источник этого лага, который на самом деле, по-видимому, является основным "базовым" лагом, ощущаемым в Spyder 4 против Spyder 3, о котором я говорил некоторое время: как предположил @bcolsen , это действительно является панелью схемы, хотя на самом деле это происходит независимо от того, открыта или закрыта указанная панель. На младшей машине это действительно видно (хотя и далеко не так плохо), если открыты только temp.py и mainwindow.py , ничего не включено и панель контура не открыта. Вот как выполнить воспроизведение из чистых настроек:

  1. Откройте mainwindow.py и разделенную панель редактора и установите для правой панели отображение temp.py, а для левой - отображение главного окна.
  2. Удерживая нажатой кнопку удаления / дублирования / перемещения строки в левой панели (в главном окне), отменить / повторить и т. Д. Для того же. Видно небольшое, но заметное отставание.
  3. Откройте панель Outline (которая по умолчанию была скрыта). Это (из-за незначительной, но полезной очевидной ошибки) рассинхронизирует файл, показанный на панели схемы, с тем, который находится в фокусе, из-за того, что он переключается на отображение активного файла на самой правой разделенной панели, а не на активной разделенной панели при открытии / не скрыто.
  4. Повторите попытку удаления / etc / lines в главном окне. Присутствует очень небольшая задержка, а частота повторения выше (вероятно, будет более заметна на машинах с более низкой производительностью)
  5. Щелкните правую панель (temp.py), а затем вернитесь на левую панель (главное окно), чтобы в проводнике схемы правильно отображался контур левой панели.
  6. Повторите удаление / и т. Д., И задержка вернется, как на шаге 2 (когда проводник контуров не был виден вообще)

Чтобы проверить это со многими файлами, я выполнил поиск import os в каталоге spyder , открыл первые 40-50 файлов в режиме разделенной панели (меньшее количество файлов большего размера должно дать аналогичный эффект) и повторил шаги. 2-6 выше. Даже для короткого файла при удалении строк на шагах 2 и 6 наблюдалась гораздо большая задержка (аналогичная уровню направляющей отступа в главном окне) (проводник контуров скрыт и отображается в активном файле), в то время как по существу не было задержка (как если бы файлы не были открыты или уровень Spyder 3) на шаге 4 (проводник схемы открыт и деинхронизирован с активным файлом).

Между тем, при включении направляющих отступов в обоих случаях удаление строк / etc происходило очень медленно, независимо от количества открытых файлов, и на результирующую задержку, по-видимому, существенно влияла только длина текущего изменяемого файла и количество отображаемых разделенных панелей. файл.

  1. Откройте панель Outline (которая по умолчанию была скрыта). Это (из-за незначительной, но полезной очевидной ошибки) рассинхронизирует файл, показанный на панели схемы, с тем, который находится в фокусе, из-за того, что он переключается на отображение активного файла на самой правой разделенной панели, а не на активной разделенной панели при открытии / не скрыто.

Это действительно похоже на то, что я испытываю, но просто добавляю еще одну деталь: я работаю с одним отдельным окном редактора на другом дисплее и закрываю панель редактора в Spyder каждый раз, когда запускаю его. Так что я все еще сталкиваюсь с этой ошибкой с одним окном редактора без разделенных панелей, если это актуально. Направляющие отступа также занимают намного больше времени.

Надеюсь, вы найдете ответ, и это скоро будет исправлено, поэтому я смогу использовать отличный темный режим в 4.0.0.

Я могу подтвердить, что каждый раз, когда добавляется или удаляется строка, планировщик обновляет все открытые файлы. Это приводит к увеличению времени на удаление / добавление строк, которое увеличивается с количеством открытых файлов. Я сделал простое «исправление» в приведенном выше PR, которое, кажется, решает проблему со многими открытыми файлами. @ impact27 Мысли?

Отдельная, но очевидно связанная проблема заключается в том, что большие файлы (> 2000 строк) также медленно обновляются с изменением строк. Наличие 4 или 5 из этих больших файлов в настоящее время делает работу еще медленнее с update_all make. С вышеуказанным патчем проблема, описанная @ CAM-Gerlach, по-прежнему будет возникать с большим файлом, но маленький файл всегда должен быть быстрым.

Отдельная, но очевидно связанная проблема заключается в том, что большие файлы (> 2000 строк) также медленно обновляются с изменением строк. Наличие 4 или 5 из этих больших файлов в настоящее время делает работу еще медленнее с update_all make. С вышеуказанным патчем проблема, описанная @ CAM-Gerlach, по-прежнему будет возникать с большим файлом, но маленький файл всегда должен быть быстрым.

Похоже, нам нужно перенести процесс блокировки UI в поток.

Похоже, нам нужно перенести процесс блокировки UI в поток.

Это было бы лучше всего. Однако я думаю, что на тот момент это связано с подсветкой синтаксиса.

Однако я думаю, что на тот момент это связано с подсветкой синтаксиса.

Да, это проблема, поскольку инфраструктура подсветки синтаксиса Qt работает в основном потоке: - \

@bcolsen В дополнение к обновлению только текущего файла, он также не должен обновляться, если проводник структуры даже не отображается (как сейчас подтверждают мои испытания).

У меня такая же проблема.
Spyder стал крайне медленным.
Я надеюсь, что мне нужно обновить какие-то пакеты.

@NaderNazemi Как видно из проблемы, мы выполнили всестороннее тестирование, изолировали причины проблемы и уже внедрили исправление, которое в основном должно решить эту проблему в Spyder 4.0.1, который будет выпущен очень скоро, с дополнительными улучшениями в путь. Наберитесь терпения, иначе, если вы опытный пользователь, вы можете протестировать последнюю ветку разработки Spyder с Github, чтобы самостоятельно опробовать исправление. Благодарю.

Я вижу, что это исправлено, но в моей версии 4.1.4 (возможно, есть более новые версии) проблема возникает, когда приложение автозаполнения Kite закрывается.

Привет, @DGuidi , спасибо, что

Что касается Kite, я не использую его и его сторонний проприетарный плагин, но похоже, что вы изолировали конкретный случай, когда он медленный, что действительно помогает решить его, поэтому, надеюсь, один из их разработчиков или кто-то остальное так склонен, сможет разобраться в чём дело. Удачи!

@ CAM-Gerlach и все остальное, просто чтобы добавить некоторую информацию, я использую WinPython64-3.8.5.0cod из https://winpython.github.io/, поэтому, возможно, проблема связана с некоторой конфигурацией в этом пакете или, может быть, в моих окнах машина.
Мне сложно обновить версию spyder, по крайней мере, до обновления winpython: у меня нет возможности устанавливать программное обеспечение на свой компьютер.

Отключение автозавершения кайта, а также запасное завершение НЕ работает для меня :(

Screenshot_362

@stonebig Может быть, вы что-нибудь знаете об этом?

На данный момент вы можете попробовать отключить любые параметры в меню Source , Preferences > Editor и Preferences > Completion and Introspection которые вам особо не нужны, особенно направляющие с отступом, которые могут вызвать значительную задержку. Помимо этого, у нас есть ряд исправлений, готовых или находящихся в финальном тестировании для Spyder 4.2.0, которые будут выпущены в ближайшие несколько недель, которые направлены на повышение производительности редактора и устранение большинства причин замедления, особенно для больших файлов, но, не имея возможности протестировать их, чтобы убедиться, что они улучшают ситуацию для вас, я не совсем уверен, что еще рекомендовать, извините.

Привет @ CAM-Gerlach, 95% времени Windows работает очень медленно, это связано с антивирусной активностью или переполнением памяти.

Кроме того, дополнительные плагины Spyder не могут улучшить ситуацию.

Хорошо спасибо. Надеюсь, 4.2.0 решит или, по крайней мере, значительно улучшит ситуацию для @DGuidi.

Была ли эта страница полезной?
2 / 5 - 1 рейтинги