cygwin grep rodando 680 vezes mais rápido via ssh do que via desktop remoto

Question

Executando o grep abrindo o terminal Cygwin via Microsoft Remote Desktop para o Windows Server 1012 R2 (o mesmo que nativamente?):

Administrator@MYSERV /cygdrive/d/bin/beta
$ time grep -inowf matchfile_431184247462809.temp infile_431184247462809.temp > delme

real    1m40.568s
user    1m40.405s
sys     0m0.140s

Exatamente o mesmo comando, nos mesmos arquivos, executado quando conectado via Cygwin SSH:

Administrator@MYSERV /cygdrive/d/bin/beta
$ time grep -inowf matchfile_431184247462809.temp infile_431184247462809.temp > delmessh

real    0m0.148s
user    0m0.140s
sys     0m0.000s

grep.exe executável é o mesmo, o arquivo de saída é o mesmo, mas o tempo de execução é dividido em segundo vs. quase 2 minutos.

Dado que o cygwin SSH é executado sob a configuração especial do usuário, eu tentei ssh localhost na área de trabalho remota; o tempo de execução: 1 minuto e 40 segundos.

Existe alguma explicação lógica ou ilógica para isso? Quaisquer configurações que eu possa verificar no Windows Server 2012 que suprimam artificialmente processos de área de trabalho remota?

Atualização: a execução de C: \ cygwin \ bin \ grep.exe a partir da linha de comandos do Windows cmd também é instantânea. Portanto, há um problema com o terminal Cygwin.

Atualização 2: Eu pesquisei que ter compartilhamentos de arquivos mortos no PATH pode atrasar o terminal do Bash. Ao contrário da minha esperança inicial, apagar a variável $ PATH não fez nada. Eu também não tenho nenhum link morto no PATH.

Solução, parabéns ao @Paul Haldane : Grep parece ser descartado pelo valor $LANG de en_US.UTF-8 , que é padrão no Cygwin. Isso atinge o desempenho de regex especialmente difícil. A execução de grep -F também foi mais lenta, mas apenas por um fator de 4.

Aqui está uma verificação em um servidor separado:

$ echo $LANG
en_US.UTF-8

$ time grep -inowf matchfile_431184247462809.temp infile_431184247462809.temp > delme

real    1m56.425s
user    1m56.218s
sys     0m0.171s

$ LANG=''

$ time grep -inowf matchfile_431184247462809.temp infile_431184247462809.temp > delme2

real    0m0.286s
user    0m0.265s
sys     0m0.015s

$ diff delme delme2
** no difference **

    

Answer 1

Solução, parabéns para @Paul Haldane :

There was a bug in grep which resulted in slow searches when LANG was set to something other than C – Paul Haldane 22 hours ago

O grep parece ser descartado pelo valor $ LANG do en_US.UTF-8, que é padrão no Cygwin. Isso atinge o desempenho de regex especialmente difícil. A execução do grep -F também foi mais lenta, mas apenas por um fator de 4.

Aqui está uma verificação em um servidor separado:

$ echo $LANG
en_US.UTF-8

$ time grep -inowf matchfile_431184247462809.temp infile_431184247462809.temp > delme

real    1m56.425s
user    1m56.218s
sys     0m0.171s

$ LANG=''

$ time grep -inowf matchfile_431184247462809.temp infile_431184247462809.temp > delme2

real    0m0.286s
user    0m0.265s
sys     0m0.015s

$ diff delme delme2
** no difference **

    

Answer 2

Por um ssh adiciona sobrecarga por causa da criptografia, mas isso não explica o salto de segundos para minutos, o que explica é o fato de que o Cygwin emula um terminal Unix e a emulação é lenta. Você pode encontrar mais detalhes sobre isso no link

da Wikipédia.

Essa parte explica muito bem

A chamada do sistema fork para duplicar um processo é totalmente implementada, mas não é bem mapeada para a API do Windows. Por exemplo, a estratégia de otimização de cópia na gravação não pôde ser usada. [5] [6] [7] Como resultado, o fork do Cygwin é bastante lento se comparado ao Linux e outros. (Essa sobrecarga geralmente pode ser evitada substituindo os usos da técnica fork / exec pelas chamadas para as funções de spawn declaradas no cabeçalho process.h específico do Windows).