Isso é verdade para shells que em time é programa externo ou um comando interno.
Na verdade, seu código em subshell nem funciona em shells que têm o time que tem essa restrição, como o dash, já que o ( também é um grupo de comandos (só que rodados numa fork() do shell atual).
$ dash -c 'time ( echo Estou no subshell. )'
dash: 1: Syntax error: word unexpected (expecting ")")
O bash (assim como os *ksh) implementa o time como uma palavra-chave, o que significa que, qualquer coisa que você possa digitar no shell, pode ser medida (incluindo pipelines com múltiplos comandos, grupos de comandos, etc.
Enfim, a discussão aqui é meio bizantina, o tempo gasto no fork() → exec() é desprezível em comparação com os comandos que rodam dentro do subshell – mas em outros casos, pode distorcer os resultados em favor do comando simples sem ().
Usando um exemplo um pouco mais realista de como isso de ( e sem podem afetar:
$ time tr '[:lower:]' '[:upper:]' < 2000linhas.txt > /dev/null
real 0m0,001s (máximo)
user 0m0,000s
sys 0m0,001s
$ time (tr '[:lower:]' '[:upper:]' < 2000linhas.txt > /dev/null)
real 0m0,003s (mínimo)
user 0m0,002s
sys 0m0,001s
Isso pode não fazer a diferença num comando trivial, ou num único comando gigante, mas numa sequência de comandos pequenos, a distorção pode se acumular.
No dash, você realmente tem que fazer um único comando (trazendo penalidades parecidas ao ( do bash):
time dash -c 'echo 1; echo 2;'
Para tornar a comparação honesta, é interessante fazer o mesmo com o comando simples.
Mas eu concordo, realmente você encontra este tipo de amplificação no shell dependendo de como o comando é construído e recurções e loops são tratados só não diria que são simples considerando o nível de abstração escondendo o trabalho. De qualquer forma bem interessante!
E ele esbarrou já de cara no clássico “100% transferido só que não” por estar transferindo um arquivo grande o bastante para resultar nesse bug… Isso já foi discutido aqui, mas aparentemente para muita gente esse problema não existe de verdade…
Ninguém vai apostar isso com você, da mesma forma que ninguém vai ver a maioria desses defeitos que muitas vezes fanboys de interface ou distro X e Y não enxergam. Porque ninguém quer ver nada que não o afeta pessoalmente, mesmo que um famoso de TI passe por isso ao vivo.
Se não me engano este bug está relacionado com ele ainda passar o resto do arquivo armazenado em buffer para o destino, mesmo o processo em 100% (o mesmo ocorre com o dd)
é inevitável passar pelo buffer do kernel, é necessário, não é seguro escrever diretamente no dispositivo, o problema é você passar tudo rapidamente para o buffer do kernel, o sistema só monitora a transferência para o buffer, não do buffer para o dispositivo. Eu cheguei a fazer uma demonstração em C de como corrigir esse problema, consiste em alimentar o buffer de forma controlada, em alguns casos melhora a performance porque idealmente nenhum processo deveria sobrecarregar o buffer que é compartilhado entre todos os dispositivos, esta sobrecarga resulta em overhead da gestão da queue do buffer.
Claro q n vai apostar. Ninguém gosta de perfer dinheiro. Então deixo a lição pra vc: Não trate problemas isolados no seu computador como característica geral.
Pessoal usa distro feita pelo zezinho youtuber 123, ou fica mexendo em configurações q n sabe pra dps culpar o Linux por problemas q (na maioria das vezes) o próprio usuário causou.
Não é isso, é que ninguém quer apostar quando está na mesa a regra “se quer apostar comigo tem que saber que eu sempre vou vencer porque essa é a regra”. Da mesma forma que ninguém vai ver problema algum se não quiser ver. Não tenho nada contra quem quer por as coisas dessa forma de qualquer forma, eu sei que disse o óbvio.
Tá. Pois n precisamos apostar. Vamos só esclarecer q esse n é uma característica do Linux pode ser? Afinal, se fosse era para o problema ocorrer comigo tmb. Vc concorda?
O que acontece é isso: minhas transferências ocorrem normalmente e da mesma forma no meu Ubuntu, Windows 10 e Mac. Se vc quiser verificar por si só estarei a disposição para gravar um vídeo demonstrando q n tenho esse tipo de problema. Até onde sei eu n sou especial pra só eu no mundo Linux n ter esse tipo de problema certo?
Kkk. N pow. Eu n tô negando q esse problema exista. Tô dizendo é q ao meu ver é caso isolado, justamente porq eu n tenho. Eu sei q problema é esse. Acompanhei um post aki no fórum sobre isso. O que eu quero entender é porq estão tratando como característica sendo q nos meus computadores com Ubuntu não ocorre. E não sei porq vc se esquiva tanto de fazermos os testes. Isso n iria provar um de nossos pontos? Vou dar um exemplo: vc grava um vídeo mostrando o problema. E aí eu gravo o meu fazendo exatamente e com o mesmo arquivo todos os passos q vc fez. Eai vamos ver se isso é realmente um bug geral. Q tal?