我打电话给哪一个？
是否有必要同时打电话？
如果我已经打过其中一个,那么另一个会抛出异常吗？
垃圾回收器可以为.NET进程分配的最大内存是多少？当我编译为x64时,Process.GetCurrentProcess.MaxWorkingSet返回大约1,4GB,但是当我编译到AnyCPU(x64)时,返回相同的数字.对于x64,它应该更像是任务管理器中显示的"限制"值.如何在所有情况下获得超出OutOfMemory-Exceptions的正确数字？
一些示例应该返回的方法:
1)机器配置:x64-Windows,4GB物理内存,4GB页面文件
- 作为64位进程:8GB
-As 32位进程:1.4GB
2)机器配置:x64-Windows,1GB物理内存,2GB页面文件
- 作为64位进程:3GB
-As 32位进程:1.4GB
3)机器配置:x32-Windows,4GB物理内存,4GB页面文件
- 作为64位进程:不会发生
- 作为32位进程:1.4GB
4)机器配置:x32-Windows,512MB物理内存,512MB页面文件
- 作为64位进程:不会发生
- 作为32位进程:1.0GB
在我的Azure角色代码中,我下载了一个400兆字节的文件,该文件被拆分为10兆字节的块并存储在Blob存储中.我CloudBlob.DownloadToStream()用于下载.
我尝试了两种选择.一个是使用FileStream- 我创建一个"写" FileStream并逐个下载块到同一个流而不倒带,所以我最终得到一个原始文件.另一个选择是MemoryStream通过传递一个比原始文件大小稍大的数字作为流大小(以避免重新分配)并将块下载到其中来创建对象MemoryStream- 这样我最终得到一个MemoryStream保存原始文件数据.
这是一些伪代码:
var writeStream = new StreamOfChoice( params );
foreach( uri in urisToDownload ) {
blobContainer.GetBlobReference( uri ).DownloadToStream( writeStream );
}
现在唯一的区别是,它是FileStream一个案例而另一个案例,MemoryStream其余部分是相同的.事实证明,它需要大约20秒,FileStream大约需要30秒MemoryStream- 是的,FileStream结果更快.根据\Memory\Available Bytes性能计数器,虚拟机在MemoryStream创建之前具有大约1千兆字节的可用内存,因此不是由于分页.
为什么写入文件的速度要快于MemoryStream？