Ipython: Медленное завершение табуляции на большом объекте данных в записной книжке

Долго ли занимает repr(x) с этими массивами? О подобной проблеме сообщалось как jupyter / qtconsole # 90. Код завершения завершается косвенным вызовом repr для объектов. В настоящее время мы не знаем, как этого избежать.

repr работает несколько медленнее, но в некоторых наборах данных завершение табуляции было намного медленнее, чем repr и по крайней мере в одном случае блокнот завис (и, если я правильно помню, также использовал тонну памяти - Нет времени заново обновлять и проверять). Это было вызвано использованием геопанд для загрузки глобального шейп-файла стран (http://www.naturalearthdata.com/downloads/10m-cultural-vectors/10m-admin-0-countries/) и запуском завершения табуляции - обратите внимание, что теперь Я смотрю на него еще раз, это на самом деле небольшой файл.

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

Джедаи могут проверять вещи, даже если их результаты не отображаются в записной книжке. Существует тайм-аут, который должен остановить джедаев для проверки вещей через ~ 0,8 секунды (как только джедаи дадут нам изменение, чтобы отменить его), и у джедаев есть свои параметры конфигурации, чтобы изменить свою агрессивность при проверке. IPython должен вести себя, если jedi не установлен, поэтому вы можете удалить его, чтобы узнать, является ли это причиной.

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

У меня именно такая проблема с большими фреймами данных pandas. Как описано, repr занимает некоторое время, но не столько, сколько отстает, возможно, repr вызывается повторно при каждом нажатии клавиши?

Кажется, это происходит вместе с https://github.com/ipython/ipython/issues/9879, но я не понимаю, связаны ли они (подробнее см. В этом билете).

Это с jedi==0.10.2 . Когда я снимаю джедаев, все становится гладко, как масло, что говорит о том, что проблема в этом. Когда я устанавливаю jedi из HEAD с помощью pip install -e git://github.com/davidhalter/jedi.git#egg=jedi (в настоящее время при фиксации e2f88db3c227965179d472f5e0d6a07b34e6f364), он все еще довольно медленный.

Ссылка на связанную проблему в джедаях: https://github.com/davidhalter/jedi/issues/919

А пока, похоже, есть способ отключить джедаев в ipython с помощью Completer.use_jedi : https://ipython.readthedocs.io/en/stable/config/options/terminal.html

В частности, вы можете использовать ipython locate profile чтобы найти текущий каталог профиля, и отредактировать ipython_config.py чтобы добавить c.IPCompleter.use_jedi = False

У меня такая же проблема с очень медленной проверкой объектов с помощью TAB, и после применения вышеуказанного исправления отказа от использования джедаями это вообще не проблема (с использованием текущих версий conda-forge в текущей macOS).
Мой объект, который я проверяю, создается этим кодом на случай, если кто-то захочет что-то проверить:

https://github.com/michaelaye/planet4/blob/master/planet4/io.py#L452 -L572

Думаю, джедаи действительно подходят к концу. ;)

@michaelaye Я думаю, что это отдельная проблема, потому что похоже, что repr() вашего объекта нужно быстро вычислить. Может быть, его вызывающие свойства? Похоже, что некоторые из этих свойств запрашивают файл.

Если у вас есть свободное время, пожалуйста, поговорите с @Carreau , который возглавляет интеграцию джедаев, чтобы мы могли разработать правильное решение этой проблемы - мы добавляем интеграцию джедаев с конечной целью замена нашего собственного оборудования для обнаружения заканчивания, поэтому отказ от джедаев - это строго краткосрочное решение. Он не должен вызывать такие свойства.

Если у вас есть свободное время, пожалуйста, поговорите с @Carreau , который возглавляет интеграцию джедаев, чтобы мы могли разработать правильное решение этой проблемы - мы добавляем интеграцию джедаев с конечной целью замена нашего собственного оборудования для обнаружения заканчивания, поэтому отказ от джедаев - это строго краткосрочное решение. Он не должен вызывать такие свойства.

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

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

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

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

Возможно, связанная проблема: https://github.com/davidhalter/jedi/issues/931

У меня тоже была эта проблема, и, похоже, обновление jedi до 0.11.0 с 0.10.2 решило это для меня. Было бы здорово, если бы это подтвердили другие. Спасибо!

@joonro
Да, у меня тоже сработало обновление до jedi==0.11 !

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

Да-аш. Запросы на завершение помещаются в ту же очередь, что и запросы на выполнение, поэтому они не получат ответа во время выполнения кода. Во внешнем интерфейсе есть очень простой механизм завершения, позволяющий выбирать слова, которые вы уже использовали, поэтому вы все равно должны их видеть, даже если ядро ​​занято.

jedi==0.11 определенно делает это быстрее, теперь это нормально для большинства обычных случаев, за исключением случаев, когда я делаю df.<tab> или что-то в этом роде, и в результате получается большой список, тогда это занимает некоторое время. Но, с моей точки зрения, теперь он в высшей степени полезен 🎉

У меня очень похожая / связанная проблема: инспектор документации shift-tab работает очень медленно. Я пытался следовать вашим шагам (например, jedi thing == False, я также обновил jedi до 0.11) в надежде найти решение, но я все еще сталкиваюсь с этой досадной проблемой.

Я заметил следующие вещи:

• Этим утром у меня не было этой проблемы: я начал замечать это после того, как выключил ноутбук, когда у меня постоянно работала ячейка (как соединение между двумя фреймами данных pandas - размером примерно 17 МБ
  каждый).
• Вкладка shift работает нормально, если я вызываю ее для функций, вызываемых из небольшого объекта, такого как список (например, lst.apply () в порядке), но как только я вызываю ее из своего «большого» фрейма данных, он застревает (например, df ['Column1']. Apply () является проблемой).
• Инспектор документации сразу показывает, если я вручную прерываю ядро, предполагая, что документация была готова, но ядро ​​все еще работало по неизвестным причинам.

Я надеюсь, что кто-то может мне помочь.

Это некоторая информация о моем окружении.

{'commit_hash': 'ca5443062',
'commit_source': 'установка',
'default_encoding': 'cp1252',
'ipython_path': 'C: \ Users \ rusia \ Anaconda3 \ lib \ site-packages \ IPython',
'ipython_version': '6.2.1',
'os_name': 'nt',
'платформа': 'Windows-10-10.0.16299-SP0',
'sys_executable': 'C: \ Users \ rusia \ Anaconda3 \ python.exe',
'sys_platform': 'win32',
'sys_version': '3.6.1 | Anaconda 4.4.0 (64-разрядная версия) | (по умолчанию, 11 мая 2017 г., '
'13: 25: 24) [MSC v.1900, 64 бит (AMD64)] '}

ОБНОВЛЕНИЕ: я даже попытался переустановить дистрибутив Anaconda и всю записную книжку, и проблема не исчезла.

Не могли бы вы попробовать с Python 3.7?

Вероятно, https://github.com/python/cpython/pull/2132 поможет.

Вы также можете посмотреть https://github.com/davidhalter/jedi/pull/922

В jupyter просто запустите ячейку со следующим содержимым %config IPCompleter.use_jedi = False

Я использую jedi 0.13.3, и это все еще серьезная проблема, которая значительно замедляет мое кодирование. Мне часто приходится узнавать что-то новое. На данный момент я отключил джедаев, но подсказки, которые он давал, более полны, чем автозаполнение по умолчанию.

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

Какой статус у этого? Разве джедаи просто не рекомендуются для больших наборов данных? это планируется когда-нибудь исправить?
@Carreau

это планируется когда-нибудь исправить?

В настоящее время я - практически - единственный сопровождающий IPython, и это не моя постоянная работа.
У меня нет в настоящее время планов, чтобы лично исправить это. У меня нет ни времени, чтобы разобраться в этом, ни средств, чтобы нанять кого-нибудь для этого. Что ж ... Будет ли это исправлено, зависит от сообщества.

В настоящее время мои приоритеты:
1) Будьте любезны и постарайтесь хотя бы отвечать на все новые вопросы и пиар.

• Я буду уделять первоочередное внимание тому, чтобы быть вежливым с новичками и представителями меньшинств, а также отвечать на простые и прямолинейные вопросы и PR. У меня редко бывает двухчасовой блок, который я могу посвятить сложным вещам.
  2) Ремонтопригодность, документация и регулярный выпуск проекта.
  
  
  
  • В основном это заканчивается одна пятница во второй половине дня в месяц, чтобы делать примечания к выпуску и сам выпуск.
  
  

Остальное хорошо ... доступно, и может зависеть от того, над чем я хочу работать.

Мы, конечно, всегда ищем более вовлеченных участников, которые помогут поддерживать проект, и ищем способ сделать их основным разработчиком с правами на коммит.

@michaelaye @yogevyuval

У меня нет времени смотреть на эту ошибку, но я кое-что исправил, не имея особых знаний об IPython или джедаях.
Я бы посоветовал:

1. Убедитесь, что у вас установлены последние версии IPython, Jedi и Python (3.7).
2. Найдите минимальный пример.
   Если это подразумевает __repr__() вы можете использовать этот тип класса для его идентификации:
   `` питон

    class SlowRepr():
        "class to test what happens if __repr__ is very slow."
        def some_method(self):
            pass
        def __repr__(self):
            time.sleep(2)
```

1. Убедившись в точной причине, замените time.sleep() на pdb.set_trace() или traceback.print_stack() чтобы определить место вызова __repr__() .
2. Поймите, почему вы закончили здесь (это сложная часть), и выясните, нежелательное ли это поведение.
3. Внесите исправление и предложите запрос на перенос.