时间花在做工作上
该命令不会挂起或等待浪费时间，
它确实会花费时间。通过增加多个小的网络延迟，很可能需要时间。但也可能是youtube方面的延迟加起来了。
只是下载所需HTML所需的时间；
该命令至少需要发出两个HTTP请求，一个接一个，甚至可能更多。
因此，如果一切缓慢，则将其乘以已经请求的数量。
对我来说，在一条非常快的线上需要1.5秒-与8秒相差不远。
如何找出
我将显示用于查找的命令：
为了使示例更简洁，我们对URL使用一个变量：
$ u="https://www.youtube.com/watch?v=k4JGSAmu4lg"
我们要测量命令的持续时间；使用该命令时time需要注意不要混淆该命令和内置的shell。我们使用一个小函数来缩短行数：
$ t(){/usr/bin/time -f 'Time: %es' "$@";}
您的命令写出视频文件的URL（截断为80列）：
$ youtube-dl -g "$u"
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?signature=091F68E823
我们来衡量一下在我的计算机上运行所花费的时间：
$ t youtube-dl -g "$u"
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?signature=091F68E823
Time: 1.44s
好，一个半秒。比问题快，但没有那么快。但是如何花费时间呢？也许它确实以某种隐藏的方式下载了视频并丢弃了它？视频是360p的11分钟。仅下载它就没有选项，大约需要13秒-延长了十倍。
需要仔细了解一下，使用verbose选项-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
哦，打印“ [debug]”行之前会有一些延迟。看起来youtube-dl要花一些时间进行自己的配置设置。这是四分之一秒左右，而不是我们正在寻找的延迟。但是我们可以从中学到的是，youtube-dl实现本身可能很慢。
消息之后，直到打印结果URL为止，什么都不会发生。因此，我们仍然看不到有趣的部分。从某种意义上说，
该选项-g是“模拟”视频下载，因为它完成了查找半秘密URL的复杂部分，将其打印出来，但最后跳过了实际下载。有一个类似的选项-s，它不输出URL，否则看起来类似。假设它花费的时间差不多，就足够相似了。我们需要检查一下。
$ 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
好的，-s与的时间相同-g，因此可以替换它们进行测试。
更有趣的是，我们现在获得了更多的输出。它的打印时机很有趣：行的打印时延彼此相似，因此看来它们与实际花费我们寻找时间的动作有关。
从消息中下载至少两个网页。但是我们可以假设“页面”一词并不意味着一个HTTP请求和一个HTML文档。
我们学到了什么？
要点是，程序的工作确实需要时间，它不是在等待或挂起。
同样，我们看到多个步骤花费了相似的时间。没什么可计算的，因此网络往返以某种方式加起来。
这意味着，连接的延迟仅在此处很重要。连接的吞吐量无关紧要。
如果您可以加快Internet连接的速度，使其可以以两倍的速度传输数据，那根本没有帮助。但是，如果您能度过美好的ping时光，那将使其更快。
不过，这与向互联网服务提供商“ ping”时间无关；一直到YouTube的ping时间都很重要-可能无法更改。
有趣的是，对于下一步，下载视频，对快速线路的要求正好相反：延迟根本不相关，而吞吐量确实很重要。
还不累吗
想要更多细节来了解实际花费的时间吗？
下一步将是跟踪HTTP连接。我怀疑它可能会显示比两次更多的往返，例如重定向。您可以使用wireshark或日志HTTP代理，或者strace仅计算用于连接或写入的系统调用。
时至今日，我们俩都已经深入研究了网络的无用功。