Spyder: Spyder 4.0.0 insuportavelmente lento ao adicionar ou remover linhas

@gabrielclow , sua descrição não é suficiente. Por favor, poste:

1. Que tipo de arquivo você está editando (Python ou outro)?
2. Quantas linhas seu arquivo tem?
3. Você tem recursos como "Guias de recuo" habilitados?

Finalmente, poste um problema de vídeo (gif animado com a tampa de licença) para ver a que exatamente você está se referindo.

@gabrielclow , sua descrição não é suficiente. Por favor, poste:

1. Que tipo de arquivo você está editando (Python ou outro)?
2. Quantas linhas seu arquivo tem?
3. Você tem recursos como "Guias de recuo" habilitados?

Finalmente, poste um problema de vídeo (gif animado com a tampa de licença) para ver a que exatamente você está se referindo.

1. Estou editando apenas arquivos .py
2. Não parece que depende do número de linhas. Acontece em arquivos pequenos com 50 linhas a grandes com 5k linhas.
3. Eu só uso o autocompletar (configuração na imagem). O resto é desligado (sem linting, sem linting de estilo de código, sem linting docstring, sem guias de indentação). Não tenho nenhum outro idioma configurado e também tentei ativar e desativar o Kite.

No gif, eu seguro Enter, espero as novas linhas serem criadas e, em seguida, pressiono Ctrl + Z para removê-las (o mesmo efeito de Ctrl + D, então acho que também não tem nada a ver com o atalho). O Spyder então para e adiciona ou exclui as linhas muito lentamente em vez de fazer isso suavemente:

atualização : aparentemente, se eu fechar alguns arquivos a lentidão é menos perceptível!
atualização 2 : também, a quantidade de lentidão aparentemente está relacionada ao número de arquivos abertos + número de linhas em cada arquivo, mas isso acontece independentemente do que está selecionado no momento. Se eu mantiver apenas alguns arquivos menores e fechar o resto, é muito mais suave
atualização 3 : se eu segurar por muito tempo ou pressionar muito rápido, o Spyder pode até travar por um tempo

além disso, a quantidade de lentidão aparentemente está relacionada ao número de arquivos abertos

Quantos arquivos você abriu quando viu a pior lentidão?

além disso, a quantidade de lentidão aparentemente está relacionada ao número de arquivos abertos

Quantos arquivos você abriu quando viu a pior lentidão?

Trabalho principalmente com 6 a 8 arquivos abertos. Normalmente, cerca de dois deles são maiores (4k-5k linhas) e o resto são arquivos menores com 100-500 linhas.

@ CAM-Gerlach, você já viu algo assim antes?

Se eu puder comentar sobre isso, estou tendo o mesmo problema, o que realmente me fez desinstalar o Spyder 4 e voltar para o Spyder 3.3.6.
Eu tenho apenas as configurações habilitadas que estão habilitadas no Spyder 3 também, então a verificação do PEP8; a conclusão do código e os detalhes são ativados; mas sem verificação de docstring; partes de codigo; hover descrições; pipa; etc.
A lentidão é mostrada no GIF de @gabrielclow , embora às vezes possa demorar até 2 segundos para uma única linha ser inserida.

Como eu construo grandes pacotes, não é incomum para mim ter algo como 30-50 arquivos Python abertos simultaneamente, alguns dos quais podem facilmente conter mais de 3k linhas de código (eu os tinha aberto quando percebia a enorme desaceleração).
Como eu uso 3 monitores simultaneamente para editar meus scripts na maioria das vezes, que podem conter no máximo 8 painéis, e preciso alternar entre os arquivos com frequência, fechar a maioria desses arquivos não funcionará para mim.

Pessoalmente, tenho a sensação de que o principal motivo dessa desaceleração é que há alguns bancos de dados e scripts que precisam ser atualizados / executados sempre que um arquivo aberto é modificado.

Existe, por acaso, um script que é executado em todas as linhas de todos os arquivos abertos sempre que um arquivo é modificado?
Isso explicaria por que a desaceleração parece aumentar com o número total combinado de linhas em todos os arquivos abertos e por que parece ser independente do arquivo que está sendo editado.

Eu posso confirmar esse bug. Não é tão ruim (não percebi até agora) no meu computador, mas adicionar / remover linhas é muito mais lento do que adicionar texto. O problema de entrada é realmente perceptível se você segurá-lo.

@bcolsen , como podemos reproduzi-lo?

Abra cerca de 40 arquivos e parece lento muito bem. Parece que pode haver algo em docdidchange que está verificando todos os arquivos, não apenas o ativo. Talvez o outliner.

@ ccordoba12 Pelo que eu posso dizer, este comportamento é basicamente o mesmo que # 8864, e com certeza posso reproduzi-lo com configurações limpas no Spyder 4 final com apenas mainwindow.py aberto, desde que as guias de recuo estejam habilitadas ( ter painéis divididos torna o atraso duplo ou mais). A exclusão de linhas tem o mesmo atraso principal (exatamente como descrito aqui; com latência de ~ 1s e atraso de repetição de ~ 1s em uma máquina moderadamente potente e escala proporcionalmente ao comprimento do arquivo e ao número de painéis abertos) que as outras coisas que testei lá (movendo linhas, duplicando linhas, etc), e posso confirmar que ainda acontece no Spyder 4 final com apenas o arquivo temporário e mainwindow.py aberto com configurações limpas.

No entanto, pensei que os guias de recuo não estivessem habilitados por padrão e, na verdade, eles não parecem estar habilitados depois que eu redefino as preferências, mas não consigo reproduzir em qualquer lugar perto dessa quantidade de atraso com qualquer outra configuração análise, conclusão de OTF, sublinhar erros e avisos, mostrar espaços em branco, etc); embora com todos eles habilitados para salvar guias de recuo, ele fica um pouco lento.

Existe, por acaso, um script que é executado em todas as linhas de todos os arquivos abertos sempre que um arquivo é modificado?

LSP é chamado, e inicialmente pensei que fosse isso, mas com base em seu comportamento com painéis divididos, itens específicos exibidos, mas não outros, etc. Estou pensando que pode ser relacionado ao redesenho (desenhar o arquivo inteiro em vez de apenas o visível área, etc). Mas isso está muito acima do meu nível de pagamento.

@ ccordoba12 Pelo que eu posso dizer, este comportamento é basicamente o mesmo que # 8864, e com certeza posso reproduzi-lo com configurações limpas no Spyder 4 final com apenas mainwindow.py aberto, desde que as guias de recuo estejam habilitadas ( ter painéis divididos torna o atraso duplo ou mais).

Se eu também habilitar as guias de recuo junto com meus 50 arquivos abertos e 8 painéis divididos (que é como eu geralmente edito meus arquivos), o atraso aumenta para algo entre 6 a 10 segundos por nova linha.
O computador que estou usando é uma área de trabalho de última geração, então não é realmente por causa do poder da máquina.

@dalthviz e eu tentamos reproduzir # 8864 sem sucesso. Lamento dizer, mas até que possamos reproduzi-lo, não há nada que possamos fazer a respeito.

Abra cerca de 40 arquivos e parece lento muito bem. Parece que pode haver algo em docdidchange que está verificando todos os arquivos, não apenas o ativo. Talvez o outliner.

Ok, é um bom começo. Vamos verificar este.

@ ccordoba12 Eu descobri a origem desse atraso, que na verdade parece ser o principal atraso "básico" sentido no Spyder 4 vs. Spyder 3, de que falei por um tempo: Como @bcolsen sugeriu, é de fato o painel de contorno, embora realmente ocorra independentemente de o painel estar aberto ou fechado. Em uma máquina inferior, ele é realmente visível (embora nem de longe tão ruim) com apenas temp.py e mainwindow.py abertos, nada mais habilitado e nenhum painel de contorno aberto. Veja como reproduzir a partir de configurações limpas:

1. Abra mainwindow.py e divida o painel do editor e configure o painel direito para mostrar temp.py e o esquerdo para mostrar a janela principal.
2. Mantenha pressionado excluir / duplicar / mover linha no painel esquerdo (janela principal), desfazer / refazer, etc. para o mesmo. Um pequeno, mas perceptível atraso é aparente.
3. Abra o painel Esboço (que estava oculto por padrão). Isso (devido a um pequeno, mas aparente bug) dessincroniza o arquivo mostrado no painel de estrutura de tópicos daquele em foco, devido à mudança para mostrar o arquivo ativo no painel dividido mais à direita, em vez do painel dividido ativo quando aberto / unhidden.
4. Tente deletar / etc / linhas novamente na janela principal. Muito pouco atraso está presente e a taxa de repetição é maior (provavelmente será mais perceptível com máquinas de baixo desempenho)
5. Clique no painel direito (temp.py) e, em seguida, volte ao painel esquerdo (janela principal) para fazer o explorador de contorno mostrar adequadamente o contorno do painel esquerdo.
6. Tente deletar novamente / etc., E o atraso está de volta, como na etapa 2 (quando o explorador de contorno não estava visível)

Para testá-lo com muitos arquivos, pesquisei import os no diretório spyder , abri os primeiros 40-50 arquivos em um painel dividido (menos arquivos maiores devem produzir o efeito equivalente) e repeti etapas 2-6 acima. Mesmo em um arquivo curto, havia uma quantidade muito maior de atraso (semelhante ao nível de guia de recuo na janela principal) ao excluir linhas em ambas as etapas 2 e 6 (explorador de contorno oculto e mostrado no arquivo ativo), embora essencialmente não houvesse lag (como se nenhum arquivo estivesse aberto, ou nível do Spyder 3) na etapa 4 (explorador de contorno aberto e dessincronizado do arquivo ativo).

Enquanto isso, habilitando guias de recuo para ambas as vezes, a exclusão de linhas / etc era muito lenta, independentemente do número de arquivos abertos, e o atraso resultante parecia apenas ser substancialmente afetado pelo comprimento do arquivo atual sendo modificado e o número de painéis divididos mostrando o arquivo.

1. Abra o painel Esboço (que estava oculto por padrão). Isso (devido a um pequeno, mas aparente bug) dessincroniza o arquivo mostrado no painel de estrutura de tópicos daquele em foco, devido à mudança para mostrar o arquivo ativo no painel dividido mais à direita, em vez do painel dividido ativo quando aberto / unhidden.

Isso realmente soa como o que estou experimentando, mas apenas adicionando outro detalhe: trabalho com uma janela de editor separada em outro monitor e fecho o painel do editor no Spyder toda vez que o inicio. Portanto, ainda experimento esse bug com uma única janela do editor sem painéis divididos, se isso for relevante. Guias de recuo também fazem com que demore muito mais tempo.

Espero que você possa encontrar a resposta e isso seja corrigido em breve para que eu possa usar o modo grande escuro na 4.0.0

Posso confirmar que toda vez que uma linha é adicionada ou removida, o outliner atualiza todos os arquivos que estão abertos. Isso leva a um aumento no tempo de remoção / adição de linha que aumenta com o número de arquivos abertos. Eu fiz uma "correção" simples no PR acima que parece resolver o problema com muitos arquivos abertos. @ impact27 Pensamentos?

Um problema separado, mas obviamente associado, é que arquivos grandes (> 2.000 linhas) também são lentos para atualizar com as mudanças de linha. Ter 4 ou 5 desses arquivos grandes abertos atualmente torna as coisas ainda mais lentas com update_all make. Com o patch acima, o problema que @ CAM-Gerlach está descrevendo acima ainda acontecerá no arquivo grande, mas o arquivo pequeno deve ser sempre rápido.

Um problema separado, mas obviamente associado, é que arquivos grandes (> 2.000 linhas) também são lentos para atualizar com as mudanças de linha. Ter 4 ou 5 desses arquivos grandes abertos atualmente torna as coisas ainda mais lentas com update_all make. Com o patch acima, o problema que @ CAM-Gerlach está descrevendo acima ainda acontecerá no arquivo grande, mas o arquivo pequeno deve ser sempre rápido.

Parece que precisamos mover o processo de bloqueio da IU para um thread.

Parece que precisamos mover o processo de bloqueio da IU para um thread.

Isso seria o melhor. No entanto, acho que está associado ao realce de sintaxe nesse ponto.

No entanto, acho que está associado ao realce de sintaxe nesse ponto.

Sim, isso é um problema, já que a infraestrutura do realçador de sintaxe do Qt é executada no thread principal: - \

@bcolsen Além de apenas atualizar o arquivo atual, ele também não deve atualizar se o explorador de contorno não estiver nem visível (como meu teste confirma que está agora).

Estou tendo o mesmo problema.
Spyder tornou-se extremamente lento.
Espero que haja algum pacote que eu precise atualizar.

@NaderNazemi Como você pode ver pelo problema, realizamos testes abrangentes,

Vejo que está corrigido, mas na minha versão 4.1.4 (provavelmente há versões mais recentes por aí), o problema acontece quando o aplicativo de preenchimento automático Kite é fechado.

Olá @DGuidi , obrigado por nos avisar. Apenas para sua informação, o Spyder 4.1.5 foi lançado algumas semanas atrás com algumas pequenas melhorias adicionais e várias mudanças maiores para melhorar o desempenho do Editor ao rolar, digitar e usar análise de código em tempo real / guias de recuo / etc. estão implementados para a próxima versão ou em teste agora. Se você estiver se sentindo aventureiro, seria realmente útil se você pudesse experimentar o # 13864 e ver se ele melhora as coisas para você; Também o testarei em breve.

Quanto ao Kite, não o uso e é um plugin proprietário de terceiros, mas parece que você isolou um caso específico em que é lento, o que é realmente útil para resolvê-lo, então, espero que um de seus desenvolvedores ou alguém mais alguém inclinado, será capaz de descobrir o que está acontecendo. Boa sorte!

@ CAM-Gerlach e tudo, só para adicionar algumas informações, estou usando WinPython64-3.8.5.0cod de https://winpython.github.io/ então talvez o problema dependa de alguma configuração neste pacote ou talvez em minhas janelas máquina.
É difícil para mim atualizar a versão do spyder, pelo menos até que o winpython seja atualizado: não tenho a capacidade de instalar software na minha máquina.

Desativar a conclusão da pipa e também as conclusões de fallback NÃO funciona para mim :(

@stonebig Alguma chance de você saber algo sobre isso?

Por enquanto, você pode tentar desativar quaisquer opções no menu Source , Preferences > Editor e Preferences > Completion and Introspection que você não precisa particularmente, particularmente guias de recuo que podem causar um atraso significativo. Além disso, temos uma série de correções prontas ou em teste final para o Spyder 4.2.0, a serem lançadas nas próximas semanas, que visam melhorar o desempenho do Editor e resolver a maioria das causas de lentidão, especialmente em arquivos maiores, mas sem poder testá-los para confirmar que melhoram as coisas para você, não tenho certeza do que mais recomendar, desculpe.

Olá @ CAM-Gerlach, 95% das vezes que o Windows fica lento demais, está relacionado à atividade antivírus ou à saturação da memória.

Além disso, os plug-ins opcionais do Spyder podem não melhorar a situação

Ok, obrigado. Esperançosamente 4.2.0 irá resolver, ou pelo menos melhorar muito a situação para @DGuidi