O tempo é gasto trabalhando
O comando não trava ou espera por algo que está perdendo tempo,
ele realmente funciona e leva tempo; Provavelmente leva tempo adicionando vários pequenos atrasos na rede. Mas também pode haver atrasos no lado do youtube, que se somam.
Que leva apenas o tempo necessário para baixar o HTML necessário;
O comando precisa fazer pelo menos duas solicitações HTTP, uma após a outra e provavelmente mais.
Portanto, se algo for lento, ele será multiplicado pelo número de solicitações.
Para mim, são necessários 1,5 segundos em uma linha muito rápida - isso não está longe de 8 segundos.
Como descobrir
Vou mostrar os comandos que descobri:
Para tornar os exemplos mais organizados, usamos uma variável para o URL:
$ u="https://www.youtube.com/watch?v=k4JGSAmu4lg"
Queremos medir a duração dos comandos; O uso do comando timeprecisa tomar cuidado para não misturar o comando e o shell interno. Usamos uma função pequena para tornar as linhas mais curtas:
$ t(){/usr/bin/time -f 'Time: %es' "$@";}
Seu comando grava o URL do arquivo de vídeo (truncado para 80 colunas):
$ youtube-dl -g "$u"
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?signature=091F68E823
Vamos medir o tempo que leva para executar no meu computador:
$ t youtube-dl -g "$u"
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?signature=091F68E823
Time: 1.44s
Ok, um segundo e meio. Mais rápido do que na questão, mas não muito mais rápido. Mas como está gastando o tempo? Talvez ele faça o download do vídeo de alguma maneira oculta e o descarte? O vídeo tem 11 minutos em 360p. O download sem opções leva cerca de 13s - dez vezes mais.
Precisa dar uma olhada mais de perto, com a opção detalhada -v:
$ t youtube-dl -v -g "$u"
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['-v', '-g', 'https://www.youtube.com/watch?v=k4J
[debug] Encodings: locale 'UTF-8', fs 'UTF-8', out 'UTF-8', pref: 'UTF-8'
[debug] youtube-dl version 2014.02.06
[debug] Python version 2.7.6 - Linux-3.13.0-24-generic-x86_64-with-Ubuntu-14
[debug] Proxy map: {}
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?sparams=id%2Cinitcwn
Time: 1.40s
Ah, há algum atraso antes das linhas '[debug]' serem impressas. Parece que youtube-dlleva algum tempo para sua própria configuração. São cerca de um quarto de segundo, não o atraso que estamos procurando. Mas o que podemos aprender é que a youtube-dlprópria implementação pode ser lenta.
Após as mensagens, nada acontece até que o URL do resultado seja impresso. Então ainda não vemos a parte interessante.
A opção -gé "simular" o download do vídeo no sentido de que ele faz a parte complicada de descobrir esse URL semi-secreto, imprimi-lo, mas depois pula o download real no final. Existe uma opção semelhante -sque não gera a URL e, de outra forma, parece semelhante. Vamos supor que seja semelhante o suficiente se demorar aproximadamente o mesmo tempo; Precisamos verificar isso.
$ t youtube-dl -v -s "$u"
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['-v', '-s', 'https://www.youtube.com/watch?v=k4J
[debug] Encodings: locale 'UTF-8', fs 'UTF-8', out 'UTF-8', pref: 'UTF-8'
[debug] youtube-dl version 2014.02.06
[debug] Python version 2.7.6 - Linux-3.13.0-24-generic-x86_64-with-Ubuntu-14
[debug] Proxy map: {}
[youtube] Setting language
[youtube] k4JGSAmu4lg: Downloading webpage
[youtube] k4JGSAmu4lg: Downloading video info webpage
[youtube] k4JGSAmu4lg: Extracting video information
Time: 1.45s
Ok, -sleva o mesmo tempo que -g, portanto, está tudo bem substituí-los para teste.
Mais interessante é que agora temos mais resultados. E é impresso com um timing interessante: as linhas são impressas com um atraso semelhante entre si, portanto, parece que são sobre as ações que realmente levam o tempo que procuramos.
Das mensagens, pelo menos duas páginas da web são baixadas. Mas podemos supor que a palavra "página" não signifique uma única solicitação HTTP e um único documento HTML.
O que aprendemos?
O ponto principal é que o trabalho do programa realmente leva tempo, não está esperando por algo ou está pendurado.
Além disso, vemos várias etapas que levam quantidades semelhantes de tempo. Não há muito o que calcular, portanto, isso é de alguma forma, ida e volta à rede.
Isso significa que a latência da nossa conexão é importante apenas aqui. A taxa de transferência da conexão é apenas irrelevante.
Se você tornasse a sua conexão com a Internet mais rápida para poder transferir dados em velocidade dupla - isso não ajudaria em nada. Mas se você puder obter melhores pingtempos, isso será muito mais rápido.
Não se trata de tempos de 'ping' para o seu provedor de serviços de Internet; O tempo de ping até o YouTube é o que importa - e pode não ser possível alterar.
Curiosamente, para a próxima etapa, baixar um vídeo, os requisitos para uma linha rápida são exatamente o oposto: a latência não é relevante e a taxa de transferência realmente importa.
Ainda não está cansado?
Deseja ainda mais detalhes para entender em que tempo é realmente gasto?
O próximo passo seria rastrear a conexão HTTP; Eu suspeitaria que pode mostrar muito mais ida e volta que duas, para redirecionamentos, por exemplo. Você pode usar wireshark, ou um proxy HTTP de log, ou straceapenas contar as chamadas do sistema para conexão ou gravação.
Por hoje, nós dois examinamos profundamente o buraco do coelho das redes.