Spyder: Spyder 4.0.0 incroyablement lent lors de l'ajout ou de la suppression de lignes

@gabrielclow , votre description ne suffit pas. Veuillez poster:

1. Quels types de fichiers éditez-vous (Python ou autre)?
2. Combien de lignes avez-vous?
3. Avez-vous activé des éléments tels que "Guides de retrait"?

Enfin, veuillez poster un problème vidéo (gif animé avec Licecap) pour voir à quoi vous faites exactement référence.

@gabrielclow , votre description ne suffit pas. Veuillez poster:

1. Quels types de fichiers éditez-vous (Python ou autre)?
2. Combien de lignes avez-vous?
3. Avez-vous activé des éléments tels que "Guides de retrait"?

Enfin, veuillez poster un problème vidéo (gif animé avec Licecap) pour voir à quoi vous faites exactement référence.

1. Je ne modifie que des fichiers .py
2. Cela ne semble pas dépendre du nombre de lignes. Se produit dans de petits fichiers avec 50 lignes à grands avec 5k lignes.
3. Je n'utilise que l'auto-complétion (config en capture d'écran). Le reste est désactivé (pas de peluchage, pas de peluchage de style code, pas de peluchage docstring, pas de guides de retrait). Je n'ai pas d'autres langues configurées et j'ai également essayé d'activer et de désactiver Kite.

Dans le gif, je maintiens Entrée, j'attends que les nouvelles lignes soient créées, puis maintenez Ctrl + Z pour les supprimer (le même effet que Ctrl + D, donc je suppose que cela n'a rien à voir avec le raccourci). Spyder s'arrête ensuite et ajoute ou supprime les lignes très lentement au lieu de le faire en douceur:

mise à jour : apparemment, si je ferme certains fichiers, le ralentissement est moins perceptible!
mise à jour 2 : aussi, la quantité de ralentissement est apparemment liée au nombre de fichiers ouverts + nombre de lignes dans chaque fichier, mais cela se produit indépendamment de celui actuellement sélectionné. Si je ne garde que quelques fichiers plus petits et ferme le reste, c'est beaucoup plus fluide
mise à jour 3 : si je maintiens trop longtemps ou appuie trop vite, Spyder peut même se bloquer pendant un certain temps

aussi, la quantité de ralentissement est apparemment liée au nombre de fichiers ouverts

Combien de fichiers avez-vous ouverts lorsque vous avez constaté le pire ralentissement?

aussi, la quantité de ralentissement est apparemment liée au nombre de fichiers ouverts

Combien de fichiers avez-vous ouverts lorsque vous avez constaté le pire ralentissement?

Je travaille principalement avec 6-8 fichiers ouverts. Habituellement, environ deux d'entre eux sont plus gros (4k-5k lignes) et les autres sont des fichiers plus petits avec 100-500 lignes.

@ CAM-Gerlach, avez-vous déjà vu quelque chose comme ça?

Si je peux commenter à ce sujet, j'ai également le même problème, ce qui m'a amené à désinstaller Spyder 4 et à revenir à Spyder 3.3.6.
Je n'ai que les paramètres activés qui sont également activés dans Spyder 3, donc la vérification PEP8; la complétion du code et les détails sont activés; mais pas de vérification de docstring; extraits de code; survolez les descriptions; cerf-volant; etc.
Le ralentissement est comme indiqué dans le GIF de @gabrielclow , bien que cela puisse parfois prendre jusqu'à 2 secondes pour qu'une seule ligne soit insérée.

Au fur et à mesure que je construis de gros paquets, il n'est pas rare pour moi d'avoir 30 à 50 fichiers Python ouverts simultanément, dont certains peuvent facilement contenir plus de 3k lignes de code (je les avais ouverts lorsque je remarquais le ralentissement massif).
Étant donné que j'utilise 3 moniteurs simultanément pour éditer mes scripts la plupart du temps, qui peuvent contenir un maximum de 8 panneaux, et que j'ai besoin de basculer fréquemment entre les fichiers, la fermeture de la plupart de ces fichiers ne fonctionnera pas pour moi.

J'ai personnellement le sentiment que la raison principale de ce ralentissement est qu'il y a pas mal de bases de données et de scripts qui doivent être mis à jour / exécutés chaque fois qu'un fichier ouvert est modifié.

Existe-t-il, par hasard, un script exécuté sur toutes les lignes de tous les fichiers ouverts chaque fois qu'un fichier est modifié?
Cela expliquerait pourquoi le ralentissement semble évoluer avec le nombre total combiné de lignes dans tous les fichiers ouverts, et pourquoi il semble être indépendant du fichier en cours d'édition.

Je peux confirmer ce bug. Ce n'est pas si grave (je n'ai pas vraiment remarqué jusqu'à présent) sur mon ordinateur, mais ajouter / supprimer une ligne est beaucoup plus lent que d'ajouter du texte. Le problème d'entrée est vraiment perceptible si vous le maintenez enfoncé.

@bcolsen , comment pouvons-nous le reproduire?

Ouvrez environ 40 fichiers et cela semble ralentir assez bien. Il semble qu'il y ait quelque chose dans docdidchange qui vérifie tous les fichiers et pas seulement le fichier actif. Peut-être l'outliner.

@ ccordoba12 Autant que je mainwindow.py ouvert tant que les guides d'indentation sont activés ( avoir des volets séparés fait doubler ou plus le décalage). La suppression de lignes a le même décalage majeur (exactement comme décrit ici; avec une latence de ~ 1s et un délai de répétition de ~ 1s sur une machine moyennement puissante, et s'adapte proportionnellement à la longueur du fichier et au nombre de volets séparés ouverts) que les autres choses que j'ai testées là (lignes mobiles, lignes dupliquées, etc.), et je peux confirmer que cela se produit toujours sur Spyder 4 final avec seulement le fichier temporaire et mainwindow.py ouvert avec des paramètres propres.

Cependant, je pensais que les guides d'indentation n'étaient pas activés par défaut, et en effet ils ne semblent pas être activés après avoir réinitialisé les préférences, mais je ne parviens pas à reproduire ce décalage avec un autre paramètre analyse, achèvement de l'OTF, souligner les erreurs et les avertissements, afficher les espaces vides, etc.); bien qu'avec tous les guides de retrait de sauvegarde activés, cela retarde un peu.

Existe-t-il, par hasard, un script exécuté sur toutes les lignes de tous les fichiers ouverts chaque fois qu'un fichier est modifié?

LSP est appelé, et j'ai d'abord pensé que c'était tout, mais en fonction de son comportement avec des volets séparés, des éléments affichés spécifiques mais pas d'autres, etc. zone, etc.). Mais c'est bien au-dessus de mon salaire.

@ ccordoba12 Autant que je mainwindow.py ouvert tant que les guides d'indentation sont activés ( avoir des volets séparés fait doubler ou plus le décalage).

Si j'active également les guides d'indentation avec l'ouverture de mes 50 fichiers et 8 volets séparés (c'est ainsi que j'édite habituellement mes fichiers), le décalage augmente entre 6 et 10 secondes par nouvelle ligne.
L'ordinateur que j'utilise est un ordinateur de bureau de jeu haut de gamme, donc ce n'est pas vraiment à cause de la puissance de la machine.

@dalthviz et moi avons essayé de reproduire # 8864 sans succès. Désolé de le dire, mais tant que nous ne sommes pas en mesure de le reproduire, nous ne pouvons rien y faire.

Ouvrez environ 40 fichiers et cela semble ralentir assez bien. Il semble qu'il y ait quelque chose dans docdidchange qui vérifie tous les fichiers et pas seulement le fichier actif. Peut-être l'outliner.

Ok, c'est un bon début. Nous allons vérifier celui-ci.

@ ccordoba12 J'ai découvert la source de ce décalage, qui semble en fait être le principal décalage "de base" ressenti dans Spyder 4 contre Spyder 3 dont j'ai parlé pendant un moment: comme @bcolsen l'a suggéré, il est en effet le volet de contour, bien qu'il se produise réellement indépendamment du fait que ledit volet soit ouvert ou fermé. Sur une machine bas de gamme, il est en fait visible (bien que loin d'être aussi mauvais) avec seulement temp.py et mainwindow.py ouverts, rien d'autre activé et aucun volet de contour ouvert. Voici comment repro à partir de paramètres propres:

1. Ouvrez mainwindow.py et un panneau d'édition divisé, et réglez le panneau de droite pour afficher temp.py et la gauche pour afficher la fenêtre principale.
2. Maintenez la ligne de suppression / duplication / déplacement dans le panneau de gauche (fenêtre principale), annuler / rétablir, etc. pour la même chose. Un petit mais notable décalage est apparent.
3. Ouvrez le volet Plan (qui était masqué par défaut). Cela (en raison d'un bogue apparent mineur mais utile) désynchronise le fichier affiché dans le volet de contour de celui qui est focalisé, car il bascule pour afficher le fichier actif dans le panneau divisé le plus à droite plutôt que le panneau divisé actif lorsqu'il est ouvert / non masqué.
4. Réessayez de supprimer / etc / lines dans mainwindow. Très peu de retard est présent et le taux de répétition est plus élevé (sera probablement plus perceptible avec des machines moins performantes)
5. Cliquez sur le panneau de droite (temp.py), puis revenez au panneau de gauche (fenêtre principale) pour que l'explorateur de contour affiche correctement le contour du panneau de gauche.
6. Réessayez de supprimer / etc., Et le décalage est de retour, comme à l'étape 2 (lorsque l'explorateur de contour n'était pas du tout visible)

Pour le tester avec de nombreux fichiers, j'ai recherché import os dans le répertoire spyder , ouvert les 40 à 50 premiers fichiers dans une vue de panneau divisé (moins de fichiers plus volumineux devraient produire l'effet équivalent) et répété les étapes 2-6 ci-dessus. Même sur un fichier court, il y avait un décalage beaucoup plus important (similaire au niveau du guide de retrait sur Mainwindow) lors de la suppression de lignes dans les deux étapes 2 et 6 (explorateur de contour masqué et affiché sur le fichier actif), alors qu'il n'y avait pratiquement pas lag (comme si aucun fichier n'était ouvert, ou niveau Spyder 3) à l'étape 4 (explorateur de contour ouvert et désynchronisé du fichier actif).

Pendant ce temps, l'activation des repères d'indentation pour les deux fois, la suppression des lignes / etc était très lente quel que soit le nombre de fichiers ouverts, et le décalage qui en résultait ne semblait être considérablement affecté que par la longueur du fichier en cours de modification et le nombre de volets séparés affichés le fichier.

1. Ouvrez le volet Plan (qui était masqué par défaut). Cela (en raison d'un bogue apparent mineur mais utile) désynchronise le fichier affiché dans le volet de contour de celui qui est focalisé, car il bascule pour afficher le fichier actif dans le panneau divisé le plus à droite plutôt que le panneau divisé actif lorsqu'il est ouvert / non masqué.

Cela ressemble vraiment à ce que je vis, mais en ajoutant simplement un autre détail: je travaille avec une fenêtre d'édition distincte sur un autre écran et je ferme le volet de l'éditeur sur Spyder à chaque fois que je le lance. Donc, je rencontre toujours ce bogue avec une seule fenêtre d'éditeur sans aucun volet divisé, si cela est pertinent. Les guides de retrait font également prendre beaucoup plus de temps.

J'espère que vous trouverez la réponse et que cela sera bientôt résolu afin que je puisse utiliser le grand mode sombre de la version 4.0.0

Je peux confirmer que chaque fois qu'une ligne est ajoutée ou supprimée, l'outliner met à jour tous les fichiers ouverts. Cela conduit à une augmentation du temps de suppression / ajout de ligne qui augmente avec le nombre de fichiers ouverts. J'ai fait un simple "correctif" dans le PR ci-dessus qui semble remédier au problème avec de nombreux fichiers ouverts. @ impact27 Pensées?

Un problème distinct mais évidemment associé est que les fichiers volumineux (> 2000 lignes) sont également lents à se mettre à jour avec les changements de ligne. Le fait d'avoir 4 ou 5 de ces gros fichiers ouverts actuellement rend les choses encore plus lentes avec update_all. Avec le patch ci-dessus, le problème que @ CAM-Gerlach décrit ci-dessus se produira toujours sur le gros fichier, mais le petit fichier devrait toujours être rapide.

Un problème distinct mais évidemment associé est que les fichiers volumineux (> 2000 lignes) sont également lents à se mettre à jour avec les changements de ligne. Le fait d'avoir 4 ou 5 de ces gros fichiers ouverts actuellement rend les choses encore plus lentes avec update_all. Avec le patch ci-dessus, le problème que @ CAM-Gerlach décrit ci-dessus se produira toujours sur le gros fichier, mais le petit fichier devrait toujours être rapide.

Il semble que nous devions déplacer le processus de blocage de l'interface utilisateur vers un thread.

Il semble que nous devions déplacer le processus de blocage de l'interface utilisateur vers un thread.

Ce serait mieux. Je pense que c'est associé au surligneur de syntaxe à ce stade cependant.

Je pense que c'est associé au surligneur de syntaxe à ce stade cependant.

Ouais, c'est un problème car l'infrastructure de surligneur de syntaxe de Qt fonctionne sur le thread principal: - \

@bcolsen En plus de ne mettre à jour que le fichier actuel, il ne devrait pas non plus être mis à jour si l'explorateur de contour n'est même pas visible (comme mes tests le confirment maintenant).

J'ai le même problème.
Spyder est devenu extrêmement lent.
J'espère que s'il y a des paquets que je dois mettre à jour.

@NaderNazemi Comme vous pouvez le voir sur le problème, nous avons effectué des tests complets, isolé les causes du problème et déjà implémenté un correctif qui devrait principalement le résoudre dans Spyder 4.0.1 qui sera publié très bientôt, avec plus d'améliorations sur le façon. Soyez patient, ou si vous êtes un utilisateur avancé, vous pouvez tester la dernière branche de développement Spyder de Github pour essayer le correctif vous-même. Merci.

Je vois que c'est corrigé, mais dans ma version 4.1.4 (il existe probablement des versions plus récentes), le problème se produit lorsque l'application d'autocomplétion Kite est fermée.

Salut @DGuidi , merci de nous l'avoir fait savoir. Juste pour info, Spyder 4.1.5 est sorti il ​​y a quelques semaines avec quelques améliorations mineures supplémentaires et plusieurs changements plus importants pour améliorer les performances de l'éditeur lors du défilement, de la saisie et de l'utilisation de l'analyse de code en temps réel / des guides d'indentation / etc. sont soit implémentés pour la prochaine version, soit en cours de test. Si vous vous sentez aventureux, ce serait vraiment utile si vous pouviez essayer # 13864 et voir si cela améliore les choses pour vous; Je vais également le tester sous peu.

Quant à Kite, je ne l'utilise pas et c'est un plugin propriétaire tiers, mais il semble que vous ayez isolé un cas spécifique où sa lenteur est vraiment utile pour le résoudre, alors j'espère qu'un de leurs développeurs, ou quelqu'un sinon si enclin, sera en mesure de comprendre ce qui se passe. Bonne chance!

@ CAM-Gerlach et tout, juste pour ajouter quelques informations, j'utilise WinPython64-3.8.5.0cod de https://winpython.github.io/ alors peut-être que le problème repose sur une configuration dans ce package ou peut-être dans mes fenêtres machine.
Difficile pour moi de mettre à jour la version de spyder, du moins jusqu'à ce que winpython soit mis à jour: je n'ai pas la possibilité d'installer un logiciel sur ma machine.

La désactivation de l'achèvement du kite et des complétions de secours ne fonctionne PAS pour moi :(

@stonebig Avez-vous une chance de savoir quelque chose à ce sujet?

Pour le moment, vous pouvez essayer de désactiver toutes les options du menu Source , Preferences > Editor et Preferences > Completion and Introspection dont vous n'avez pas particulièrement besoin, en particulier les guides d'indentation qui peuvent provoquer un décalage important. En dehors de cela, nous avons un certain nombre de correctifs prêts ou en phase de test final pour Spyder 4.2.0, à publier dans les prochaines semaines, qui visent à améliorer les performances de l'éditeur et à résoudre la plupart des causes de ralentissement, en particulier sur les fichiers plus volumineux, mais sans pouvoir les tester pour confirmer qu'ils améliorent les choses pour vous, je ne sais pas vraiment quoi recommander d'autre, désolé.

Salut @ CAM-Gerlach, 95% du temps Windows est très lent, c'est lié à l'activité antivirus ou à la saturation de la mémoire.

De plus, les plugins optionnels Spyder peuvent ne pas améliorer la situation

D'accord merci. Espérons que 4.2.0 résoudra, ou du moins améliorera considérablement la situation pour @DGuidi