关于 MapViewOfFile 的问题

大狗狗 2008-05-20 08:37:39
<<windows核心编程>>上说:
~~~~~~~~~~~~~~~~~~~~~
当创建了一个文件映射对象后,仍然必须让系统为文件的数据保留一个地址空间区域,并将文件的数据作为映射到该区域的物理存储器进行提交。可以通过调用M a p Vi e w O f F i l e函数来进行这项操作
PVOID MapViewOfFile(
HANDLE hFileMappingObject,
DWORD dwDesiredAccess,
DWORD dwFileOffsetHigh,
DWORD dwFileOffsetLow,
SIZE_T dwNumberOfBytesToMap);

~~~~~~~~~~~~~~~~~~~~~
该函数可以一次映射整个文件,也可只映射文件的一部分。如果一个文件较大达数百M,我要全部映射的话,会不会给系统造成较大负担特别是对内存的占用?因为前面说“将文件的数据作为映射到该区域的物理存储器进行提交”。

我目前认为应该不会造成多大负担,因为提交物理存贮器并不是要立即将文件数据转入内存。只有当用户频繁、大量对映射到进程空间中的文件视图进行操作时,系统才需要较多内存。因此可以一次映射整个文件,而不必分批映射。

请大家发表下你们的看法:)
...全文
166 4 打赏 收藏 转发到动态 举报
写回复
用AI写文章
4 条回复
切换为时间正序
请发表友善的回复…
发表回复
cnzdgs 2008-05-21
  • 打赏
  • 举报
回复
我的意思有两点:
1、可以忽略文件映射对系统的影响。
2、因为文件映射占用的进程地址空间很大,编程时要有进程地址空间的概念,对其进行合理分配。
对于将近2GB或更大的文件是不能整个映射的。此外,对于大块地址空间(几百MB)的分配应该在程序初始化时进行,因为在程序运行中地址空间很可能被切成了若干小块,虽然可用空间的总和是足够的,但是由于没有足够大的连续空间,导致分配大块内存失败。
大狗狗 2008-05-21
  • 打赏
  • 举报
回复
谢谢两位回贴,clever101 您说"地址空间就那么2G啊"就是说如果我一次mapview一个数百M的文件,而且程序没有其它大的内存请求,则还是完全可以承受的:)


cnzdgs不是第一次回我贴了,感谢关照啊:) 您的意思其实也是说文件不要太大就行,要给别的代码留下存贮请求空间。

请各位继续发表看法!
cnzdgs 2008-05-20
  • 打赏
  • 举报
回复
映射占用的是虚拟内存,不会影响系统,只会占用进程的地址空间,如果进程地址空间不足,则可能导致分配内存相关的操作失败。
clever101 2008-05-20
  • 打赏
  • 举报
回复
我用过了,感觉还是不能映射整个文件,而可以创建整个文件的map,
但是绝对没有必要将整个文件MapFileView,
每次view一小部分,然后处理,然后Unmap
再mapview另一部分....
肯定不能整个一起map的,地址空间就那么2G啊
这种处理方法决不会受2G文件的限制的

16,467

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧