El tiempo se gasta haciendo trabajo
El comando no se cuelga ni espera que algo pierda el tiempo,
en realidad funciona y lleva tiempo; Lo más probable es que tome tiempo al sumar múltiples retrasos de red pequeña. Pero también podría ser que haya retrasos en el lado de YouTube, que se suman.
Que solo se necesita el tiempo necesario para descargar el HTML;
El comando debe realizar al menos dos solicitudes HTTP, una tras otra, y probablemente más.
Entonces, si algo es lento, ya se multiplica por el número de solicitudes.
Para mí, lleva 1.5 segundos en una línea muy rápida, eso no está muy lejos de los 8 segundos.
Cómo averiguar
Mostraré los comandos que solía descubrir:
Para que los ejemplos sean más ordenados, utilizamos una variable para la URL:
$ u="https://www.youtube.com/watch?v=k4JGSAmu4lg"
Queremos medir la duración de los comandos; El uso del comando timedebe tener cuidado de no mezclar el comando y el shell incorporado. Usamos una pequeña función para acortar las líneas:
$ t(){/usr/bin/time -f 'Time: %es' "$@";}
Su comando escribe la URL del archivo de video (truncado a 80 columnas):
$ youtube-dl -g "$u"
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?signature=091F68E823
Midamos el tiempo que tarda en ejecutarse en mi computadora:
$ t youtube-dl -g "$u"
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?signature=091F68E823
Time: 1.44s
Ok, un segundo y medio. Más rápido que en la pregunta, pero no mucho más rápido. Pero, ¿cómo es pasar el tiempo? ¿Tal vez descarga el video de alguna manera oculta y lo descarta? El video es de 11 minutos en 360p. Solo descargarlo sin opciones lleva unos 13 segundos, diez veces más.
Necesita echar un vistazo más de cerca, con la opción detallada -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, hay algún retraso antes de que se impriman las líneas '[depuración]'. Parece que youtube-dlpasa algo de tiempo para su propia configuración. Es un cuarto de segundo más o menos, no el retraso que estamos buscando. Pero lo que podemos aprender de él es que la youtube-dlimplementación en sí misma puede ser lenta.
Después de los mensajes, no sucede nada hasta que se imprime la URL del resultado. Entonces todavía no vemos la parte interesante.
La opción -ges "simular" la descarga de video en el sentido de que hace la parte complicada de descubrir esa URL semisecreta, la imprime, pero luego se salta la descarga real al final. Hay una opción similar -sque no genera la URL y, de lo contrario, parece similar. Supongamos que es lo suficientemente similar si toma aproximadamente el mismo tiempo; Necesitamos verificar eso.
$ 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, -stoma el mismo tiempo que -g, así que está bien reemplazarlos para probarlos.
Más interesante es que ahora tenemos más resultados. Y se imprime con un momento interesante: las líneas se imprimen con un retraso similar entre sí, por lo que parece que se trata de las acciones que realmente están tomando el tiempo que buscamos.
De los mensajes, se descargan al menos dos páginas web. Pero podemos suponer que la palabra "página" no significará una sola solicitud HTTP y un solo documento HTML.
Que aprendimos
El punto principal es que el trabajo del programa en realidad lleva tiempo, no está esperando algo o colgado.
Además, vemos varios pasos que requieren una cantidad de tiempo similar. No hay mucho que calcular, así que eso es un viaje de ida y vuelta a la red de alguna manera, sumando.
Eso significa que la latencia de nuestra conexión es importante solo aquí. El rendimiento de la conexión es irrelevante.
Si desea que su conexión a Internet sea más rápida para que pueda transferir datos a doble velocidad, eso no ayudaría en absoluto. Pero si puede obtener mejores pingtiempos, eso lo hará mucho más rápido.
Sin embargo, no se trata de "hacer ping" a su proveedor de servicios de Internet; El tiempo de ping hasta YouTube es lo que importa, y puede que no sea posible cambiarlo.
Curiosamente, para el siguiente paso, descargar un video, los requisitos para una línea rápida son exactamente lo contrario: la latencia no es relevante en absoluto, y el rendimiento realmente importa.
¿Todavía no estás cansado?
¿Quiere aún más detalles para comprender en qué se dedica realmente el tiempo?
El siguiente paso sería rastrear la conexión HTTP; Sospecho que puede mostrar muchos más viajes de ida y vuelta que dos, por ejemplo, para redireccionamientos. Puede usar wireshark, o un proxy HTTP de registro, o stracesimplemente contar las llamadas del sistema para conectarse o escribir.
Por hoy, ambos hemos mirado lo suficientemente profundo en el agujero del conejo de las redes.