Spyder: Spyder 4.0.0 insoportablemente lento al agregar o eliminar líneas

@gabrielclow , tu descripción no es suficiente. Por favor publique:

1. ¿Qué tipo de archivos está editando (Python u otro)?
2. ¿Cuántas líneas tiene su archivo?
3. ¿Tiene habilitadas las "Guías de sangría"?

Finalmente, publique un problema de video (gif animado con Licecap) para ver a qué se refiere exactamente.

@gabrielclow , tu descripción no es suficiente. Por favor publique:

1. ¿Qué tipo de archivos está editando (Python u otro)?
2. ¿Cuántas líneas tiene su archivo?
3. ¿Tiene habilitadas las "Guías de sangría"?

Finalmente, publique un problema de video (gif animado con Licecap) para ver a qué se refiere exactamente.

1. Solo estoy editando archivos .py
2. No parece que dependa del número de líneas. Ocurre en archivos pequeños con 50 líneas a grandes con 5k líneas.
3. Solo uso autocompletar (configuración en captura de pantalla). El resto está desactivado (sin líneas, sin líneas de estilo de código, sin líneas de documentos, sin guías de sangría). No tengo otros idiomas configurados y también intenté activar y desactivar Kite.

En el gif, sostengo Enter, espero a que se creen las nuevas líneas y luego presiono Ctrl + Z para eliminarlas (el mismo efecto que Ctrl + D, así que supongo que tampoco tiene nada que ver con el atajo). Spyder luego se detiene y agrega o elimina las líneas muy lentamente en lugar de hacerlo sin problemas:

actualización : aparentemente, si cierro algunos archivos, ¡la ralentización se nota menos!
actualización 2 : además, la cantidad de desaceleración aparentemente está relacionada con la cantidad de archivos abiertos + la cantidad de líneas en cada archivo, pero ocurre independientemente del que esté seleccionado actualmente. Si solo guardo unos pocos archivos más pequeños y cierro el resto, es mucho más fluido
actualización 3 : si mantengo presionado demasiado o presiono demasiado rápido, Spyder puede incluso colgarse por un tiempo

Además, la cantidad de desaceleración aparentemente está relacionada con la cantidad de archivos abiertos

¿Cuántos archivos ha abierto cuando vio la peor desaceleración?

Además, la cantidad de desaceleración aparentemente está relacionada con la cantidad de archivos abiertos

¿Cuántos archivos ha abierto cuando vio la peor desaceleración?

Principalmente trabajo con 6-8 archivos abiertos. Por lo general, dos de ellos son más grandes (4k-5k líneas) y el resto son archivos más pequeños con 100-500 líneas.

@ CAM-Gerlach, ¿has visto algo así antes?

Si puedo comentar sobre esto, también estoy teniendo el mismo problema, que en realidad me hizo desinstalar Spyder 4 y volver a Spyder 3.3.6.
Solo tengo habilitadas las configuraciones que están habilitadas en Spyder 3 también, por lo que la verificación PEP8; la finalización del código y los detalles están habilitados; pero sin verificación de la cadena de documentos; fragmentos de código; descripciones flotantes; cometa; etc.
La ralentización es como se muestra en el GIF de @gabrielclow , aunque a veces puede tomar hasta 2 segundos para que se inserte una sola línea.

A medida que construyo paquetes grandes, no es raro que tenga como 30-50 archivos de Python abiertos simultáneamente, algunos de los cuales pueden contener fácilmente más de 3k líneas de código (las tenía abiertas cuando noté la desaceleración masiva).
Dado que uso 3 monitores simultáneamente para editar mis scripts la mayor parte del tiempo, que pueden contener un máximo de 8 paneles, y necesito cambiar entre archivos con frecuencia, cerrar la mayoría de estos archivos no funcionará para mí.

Personalmente, tengo la sensación de que la razón principal de esta desaceleración es que hay bastantes bases de datos y scripts que deben actualizarse / ejecutarse cada vez que se modifica un archivo abierto.

¿Existe, por casualidad, un script que se ejecuta en todas las líneas de todos los archivos abiertos cada vez que se modifica un archivo?
Explicaría por qué la ralentización parece escalar con el número total combinado de líneas en todos los archivos abiertos y por qué parece ser independiente del archivo que se está editando.

Puedo confirmar este error. No es tan malo (realmente no me di cuenta hasta ahora) en mi computadora, pero agregar / eliminar líneas es mucho más lento que agregar texto. El problema de entrada es realmente notable si lo mantiene presionado.

@bcolsen , ¿cómo podemos reproducirlo?

Abre unos 40 archivos y parece que va bastante lento. Parece que puede haber algo en docdidchange que esté comprobando todos los archivos, no solo el activo. Quizás el delineador.

@ ccordoba12 Por lo que puedo decir, este comportamiento es básicamente el mismo que el # 8864, y efectivamente puedo reproducirlo con configuraciones limpias en Spyder 4 final con solo mainwindow.py abiertos siempre que las guías de sangría estén habilitadas ( tener paneles divididos hace que el retraso se duplique o más). Eliminar líneas tiene el mismo retraso principal (exactamente como se describe aquí; con una latencia de ~ 1s y un retraso de repetición de ~ 1s en una máquina moderadamente potente, y escala proporcionalmente a la longitud del archivo y la cantidad de paneles divididos abiertos) que las otras cosas que probé allí (líneas en movimiento, líneas duplicadas, etc.), y puedo confirmar que todavía sucede en Spyder 4 final con solo el archivo temporal y mainwindow.py abierto con configuraciones limpias.

Sin embargo, pensé que las guías de sangría no estaban habilitadas de forma predeterminada y, de hecho, no parecen estar habilitadas después de restablecer las preferencias, pero parece que no puedo reproducir en ningún lugar cerca de esta cantidad de retraso con ninguna otra configuración (código en tiempo real análisis, finalización de OTF, subrayar errores y advertencias, mostrar espacios en blanco, etc.); aunque con todos ellos habilitados para guardar guías de sangría, se retrasa bastante.

¿Existe, por casualidad, un script que se ejecuta en todas las líneas de todos los archivos abiertos cada vez que se modifica un archivo?

Se llama a LSP, y al principio pensé que era así, pero basándome en su comportamiento con paneles divididos, elementos mostrados específicos pero no otros, etc. Creo que puede estar relacionado con redibujar en su lugar (dibujar el archivo completo en lugar de solo el visible área, etc.). Pero eso está muy por encima de mi salario.

@ ccordoba12 Por lo que puedo decir, este comportamiento es básicamente el mismo que el # 8864, y efectivamente puedo reproducirlo con configuraciones limpias en Spyder 4 final con solo mainwindow.py abiertos siempre que las guías de sangría estén habilitadas ( tener paneles divididos hace que el retraso se duplique o más).

Si también habilito las guías de sangría junto con mis 50 archivos abiertos y 8 paneles divididos (que es como suelo editar mis archivos), el retraso aumenta entre 6 y 10 segundos por línea nueva.
La computadora que estoy usando es una computadora de escritorio para juegos de alta gama, por lo que en realidad no se debe a la potencia de la máquina.

@dalthviz e intenté reproducir # 8864 sin éxito. Lamento decirlo, pero hasta que no podamos reproducirlo, no podemos hacer nada al respecto.

Abre unos 40 archivos y parece que va bastante lento. Parece que puede haber algo en docdidchange que esté comprobando todos los archivos, no solo el activo. Quizás el delineador.

Ok, ese es un buen comienzo. Revisaremos este.

@ ccordoba12 He descubierto la fuente de este retraso, que de hecho parece ser el principal retraso "de referencia" que se siente en Spyder 4 vs Spyder 3 del que he hablado durante un tiempo: como sugirió @bcolsen , es de hecho el panel de contorno, aunque en realidad ocurre independientemente de si dicho panel está abierto o cerrado. En una máquina de gama baja, en realidad es visible (aunque no tan malo) con solo temp.py y mainwindow.py abiertos, nada más habilitado y ningún panel de contorno abierto. Aquí se explica cómo reproducir desde una configuración limpia:

1. Abra mainwindow.py y un panel de editor dividido, y configure el panel derecho para mostrar temp.py y el izquierdo para mostrar la ventana principal.
2. Mantenga presionada la línea eliminar / duplicar / mover en el panel izquierdo (ventana principal), deshacer / rehacer, etc. para lo mismo. Es evidente un retraso pequeño pero notable.
3. Abra el panel Esquema (que estaba oculto de forma predeterminada). Esto (debido a un error aparente menor pero útil) desincroniza el archivo que se muestra en el panel de esquema del que está enfocado, debido a que cambia para mostrar el archivo activo en el panel dividido más a la derecha en lugar del panel dividido activo cuando se abre / unhidden.
4. Vuelva a intentar eliminar / etc / lines en mainwindow. Hay muy poco retraso y la tasa de repetición es más alta (probablemente será más notable con máquinas de menor rendimiento)
5. Haga clic en el panel derecho (temp.py) y luego vuelva al panel izquierdo (ventana principal) para que el explorador de esquemas muestre correctamente el esquema del panel izquierdo.
6. Vuelva a intentar eliminar / etc., Y el retraso vuelve, igual que en el paso 2 (cuando el explorador de esquemas no estaba visible en absoluto)

Para probarlo con muchos archivos, busqué import os en el directorio spyder , abrí los primeros 40-50 archivos en una vista de panel dividido (menos archivos más grandes deberían producir el efecto equivalente) y repetí los pasos 2-6 arriba. Incluso en un archivo corto, hubo una cantidad mucho mayor de retraso (similar al nivel de guía de sangría en la ventana principal) al eliminar líneas en los pasos 2 y 6 (explorador de contorno oculto y mostrado en el archivo activo), mientras que esencialmente no había retraso (como si no hubiera archivos abiertos, o nivel de Spyder 3) en el paso 4 (explorador de esquemas abierto y desincronizado del archivo activo).

Mientras tanto, habilitar las guías de sangría para ambas ocasiones, eliminar las líneas / etc fue muy lento independientemente de la cantidad de archivos abiertos, y el retraso resultante pareció verse afectado sustancialmente por la longitud del archivo actual que se está modificando y la cantidad de paneles divididos que se muestran el archivo.

1. Abra el panel Esquema (que estaba oculto de forma predeterminada). Esto (debido a un error aparente menor pero útil) desincroniza el archivo que se muestra en el panel de esquema del que está enfocado, debido a que cambia para mostrar el archivo activo en el panel dividido más a la derecha en lugar del panel dividido activo cuando se abre / unhidden.

Esto realmente suena como lo que estoy experimentando, pero solo agrego otro detalle: trabajo con una ventana de editor separada en otra pantalla y cierro el panel del editor en Spyder cada vez que lo inicio. Así que sigo experimentando este error con una única ventana del editor sin paneles divididos, si eso es relevante. Las guías de sangría también hacen que tarde mucho más.

Espero que pueda encontrar la respuesta y esto se solucione pronto para poder usar el excelente modo oscuro en 4.0.0

Puedo confirmar que cada vez que se agrega o se elimina una línea, el esquema actualiza todos los archivos que están abiertos. Esto conduce a aumentos en el tiempo para la eliminación / adición de líneas que aumenta con la cantidad de archivos abiertos. He hecho una simple "solución" en el PR anterior que parece solucionar el problema con muchos archivos abiertos. @ impact27 ¿Pensamientos?

Un problema separado pero obviamente asociado es que los archivos grandes (> 2000 líneas) también son lentos para actualizar con cambios de línea. Tener 4 o 5 de estos archivos grandes abiertos actualmente hace que las cosas sean aún más lentas con update_all hace. Con el parche anterior, el problema que @ CAM-Gerlach describe arriba seguirá ocurriendo en el archivo grande, pero el archivo pequeño siempre debería ser rápido.

Un problema separado pero obviamente asociado es que los archivos grandes (> 2000 líneas) también son lentos para actualizar con cambios de línea. Tener 4 o 5 de estos archivos grandes abiertos actualmente hace que las cosas sean aún más lentas con update_all hace. Con el parche anterior, el problema que @ CAM-Gerlach describe arriba seguirá ocurriendo en el archivo grande, pero el archivo pequeño siempre debería ser rápido.

Parece que necesitamos mover el proceso de bloqueo de la interfaz de usuario a un hilo.

Parece que necesitamos mover el proceso de bloqueo de la interfaz de usuario a un hilo.

Esto sería lo mejor. Sin embargo, creo que está asociado con el resaltador de sintaxis en ese punto.

Sin embargo, creo que está asociado con el resaltador de sintaxis en ese punto.

Sí, eso es un problema ya que la infraestructura de resaltado de sintaxis de Qt se ejecuta en el hilo principal: - \

@bcolsen Además de actualizar únicamente el archivo actual, tampoco debería actualizarse si el explorador de

Tengo el mismo problema.
Spyder se ha vuelto extremadamente lento.
Espero que si hay algún paquete que necesite actualizar.

@NaderNazemi Como puede ver en el problema, hemos realizado pruebas exhaustivas, aislado las causas del problema y ya implementamos una solución que debería resolverlo principalmente en Spyder 4.0.1 que se lanzará muy pronto, con más mejoras en camino. Tenga paciencia, o si es un usuario avanzado, puede probar la última rama de desarrollo de Spyder de Github para probar la solución usted mismo. Gracias.

Veo que está arreglado, pero en mi versión 4.1.4 (probablemente hay versiones más nuevas) el problema ocurre cuando se cierra la aplicación de autocompletado de Kite.

Hola @DGuidi , gracias por hacérnoslo saber. Solo para su información, Spyder 4.1.5 se lanzó hace unas semanas con algunas mejoras menores y varios cambios más importantes para mejorar el rendimiento del editor al desplazarse, escribir y usar análisis de código en tiempo real / guías de sangría / etc. están implementados para la próxima versión o están en prueba en este momento. Si te sientes aventurero, sería de gran ayuda si pudieras probar el # 13864 y ver si mejora las cosas para ti; Lo probaré en breve también.

En cuanto a Kite, no lo uso y es un complemento propietario de terceros, pero parece que has aislado un caso específico en el que es lento, lo que es realmente útil para resolverlo, así que con suerte uno de sus desarrolladores o alguien si no lo desea, podrá averiguar qué está pasando. ¡La mejor de las suertes!

@ CAM-Gerlach y todo, solo para agregar algo de información, estoy usando WinPython64-3.8.5.0cod de https://winpython.github.io/, así que tal vez el problema se base en alguna configuración en este paquete o tal vez en mis ventanas máquina.
Me resulta difícil actualizar la versión de spyder, al menos hasta que se actualice winpython: no tengo la capacidad de instalar software en mi máquina.

Desactivar la finalización de cometas y también las finalizaciones de reserva NO funciona para mí :(

@stonebig ¿ Alguna posibilidad de que sepas algo sobre esto?

Por el momento, puede intentar deshabilitar cualquier opción en el menú Source , Preferences > Editor y Preferences > Completion and Introspection que no necesite particularmente, en particular las guías de sangría que pueden causar un retraso significativo. Aparte de eso, tenemos una serie de correcciones listas o en prueba final para Spyder 4.2.0, que se lanzarán en las próximas semanas, que tienen como objetivo mejorar el rendimiento del editor y resolver la mayoría de las causas de la desaceleración, particularmente en archivos más grandes. pero sin poder probarlos para confirmar que mejoran las cosas para usted, no estoy muy seguro de qué más recomendar, lo siento.

Hola @ CAM-Gerlach, el 95% de las veces Windows es muy lento, está relacionado con la actividad antivirus o la saturación de la memoria.

Además, los complementos opcionales de Spyder pueden no mejorar la situación

Bien gracias. Con suerte, 4.2.0 resolverá, o al menos mejorará en gran medida la situación para @DGuidi