简体   繁体   English

Curl Powershell windows 10 为什么比命令提示符慢?

[英]Curl Powershell windows 10 slower than command prompt why?

Just a pretty stand curl command call an S3 end point for download using all default values.只是一个漂亮的 curl 命令调用 S3 端点以使用所有默认值进行下载。 On a mac, or on a PC using command line I get 103MBsec if cached on cdn and 80mbsec otherwise.在 Mac 上,或者在使用命令行的 PC 上,如果缓存在 cdn 上,我得到 103MBsec,否则我得到 80MBsec。 Same command, same bucket, same object, using "curl.exe" and I get 1MBSec when call through powershell. I guess powershell does something different that make it's totally slow?相同的命令,相同的存储桶,相同的 object,使用“curl.exe”,当通过 powershell 调用时我得到 1MBSec。我猜 powershell 做了一些不同的事情让它完全慢? I tried using newest curl binary but still the same.我尝试使用最新的 curl 二进制文件,但还是一样。 I guess I am misunderstanding what powershell is doing when I use a curl command我想当我使用 curl 命令时,我误解了 powershell 在做什么

curl.exe yourfileonS3 >> output.bin

To complement briantist's helpful answer :为了补充briantist 的有用答案

  • In PowerShell, the redirection operators > and >> are in effect aliases of Out-File and Out-File -Append .在 PowerShell 中, 重定向运算符>>>实际上是Out-FileOut-File -Append

  • > and >> are therefore not mere byte-stream conduits, and, in fact, PowerShell as of v7.2 does not support sending raw byte output to a file. >>>因此不仅仅是字节流管道,事实上,从 v7.2 开始,PowerShell支持将原始字节 output发送到文件。

    • Instead, PowerShell invariably decodes output from any external program as text ( [string] instances), based on the character encoding reported by [Console]::OutputEncoding] and then, on saving to the target file with Out-File (possibly via > / >> ), re-encodes these strings, using that cmdlet's default character encoding (unless overridden with -Encoding in an explicit Out-File call).相反, PowerShell总是根据[Console]::OutputEncoding]报告的字符编码,将来自任何外部程序的 output 解码为文本( [string]实例),然后在使用Out-File保存到目标文件时(可能通过> / >> ),使用该 cmdlet 的默认字符编码重新编码这些字符串(除非在显式Out-File调用中用-Encoding覆盖)。

    • Not only does this not preserve the external program's raw byte output, it adds significant overhead.这不仅不会保留外部程序的原始字节 output,还会增加大量开销。

To get raw byte processing, call cmd.exe [1] and use its redirection operators :要获得原始字节处理,请调用cmd.exe [1]并使用重定向运算符

cmd /c 'curl.exe yourfileonS3 >> output.bin'

See this answer for more information.有关详细信息,请参阅此答案


[1] On Unix-like platforms, use sh -c 'curl yourfileonS3 >> output.bin' [1] 在类 Unix 平台上,使用sh -c 'curl yourfileonS3 >> output.bin'

See mklement0's answer for full context on this (I recommend accepting that one,), and the important point that handling of byte streams in redirection is problematic and error prone in PowerShell and should be avoided.有关此的完整上下文,请参阅mklement0 的回答(我建议接受那个,),重要的一点是在 PowerShell 中处理重定向字节流是有问题且容易出错的,应该避免。


So I looked into this and I believe the reason is that >> (file redirection) is the slow part.所以我调查了这个,我相信原因是>> (文件重定向)是缓慢的部分。

I originally suspected you might be calling curl (which is aliased to Invoke-WebRequest in Windows PowerShell), but I was able to reproduce the speed difference between curl.exe directly in PowerShell vs cmd.exe , and measure it, this way:我最初怀疑您可能正在调用curl (它在 Windows PowerShell 中是Invoke-WebRequest的别名),但我能够直接在 PowerShell 和curl.exe中重现cmd.exe之间的速度差异,并通过这种方式进行测量:

# call curl.exe and do redirection in PowerShell
Measure-Command -Expression { curl.exe https://uploader.codecov.io/v0.1.0_6943/linux/codecov >> delme.bin }

del delme.bin

# call cmd.exe and do redirection there
Measure-Command -Expression { & cmd.exe /c 'curl.exe https://uploader.codecov.io/v0.1.0_6943/linux/codecov >> delme.bin' }

del delme.bin

This was enough to show a stark difference.这足以显示出明显的差异。

I also confirmed that this problem is a little bit worse in Windows PowerShell as opposed to later cross-platform versions ( pwsh.exe ).我还确认这个问题在 Windows PowerShell 中比后来的跨平台版本 ( pwsh.exe ) 更严重。 In Windows, with version 7.1.0, the same commands above still show a large difference. Windows,7.1.0版本,上面同样的命令还是有很大区别的。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM