Por que usar a opção /mt no robocopy faz com que ele faça uma pausa antes de iniciar?

Por que usar a opção /mt no robocopy faz com que ele faça uma pausa antes de iniciar?

Hoje aprendi que você pode usar o/mtmudar comrobocópiapara tornar as transferências de arquivos mais rápidas. Eu tentei algumas opções diferentes para/mt:#, incluindo 1, 8, 17, 30 e 32. Descobri que 8 (o padrão) parecia ser o mais rápido por qualquer motivo.

Acredito que/mt:1é o mesmo que não usar/mtde forma alguma. Mas quando eu não uso/mt, a transferência do arquivo começa imediatamente e posso ver o texto rolando instantaneamente. Se eu usar a opção /mt, colocando um número depois dela ou não, e qualquer número que eu usar, o robocopy será invocado e exibirá a instrução robocopy no arquivo em lote por talvez 5 a 10 segundos e então será executado (é quando finalmente vejo um texto indicando uma transferência de arquivo).

Inicialmente pensei que usar a opção /mt significaria que o arquivo em lote travaria por alguns segundos enquanto aguardava algum serviço multithread ou algo assim. Mas eu tentei /mt:1, que deveria ser o mesmo que não usá-lo, e ele trava exatamente como quando eu especifico qualquer outro número. A única vez que a transferência de arquivos é iniciada imediatamente é quando a opção /mt não é usada.

Obviamente, estou usando /mt para tornar o script mais rápido. Leva apenas cerca de 20 a 30 segundos, dependendo se /mt é usado e qual número eu uso, então cada segundo conta para tornar isso mais rápido. Como posso me livrar do atraso causado pelo uso de /mt? Pressionar spaceou ENTERnão fazer nada.

Aqui está o que está sendo usado:

robocopy "H:\LOS\DefaultCitrix\ChromeCitrix" "%userprofile%\Documents\ChromeCitrix" /e /w:1 /r:4 /mt:8

Responder1

Geralmente, quando algo é multithread, uma parte do trabalho é entregue a cada thread. Se o aplicativo quiser mostrar o progresso, ele deverá coletar o status de cada tópico e mostrá-lo para você. Quanto mais detalhados forem os detalhes, mais complexo será o processo, e realmente não faz nada de bom para você em termos de velocidade, fazer toda aquela comunicação entre threads.

Em um aplicativo de thread único, por outro lado, o trabalho pode ser simplesmente despejado no console a qualquer momento.

Para simplificar, os threads provavelmente só reportam à interface do usuário quando terminam um bloco de trabalho.

informação relacionada