[英]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-File
和Out-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.