想象一下,我正在制作游戏
这是否意味着在进程的64位Virtual Address Space
中,我会想要剩下32位来玩我想要的?
我可以 - 例如 - 游戏中的每个容器(容器= std::vector
之类的东西)使用VirtualAlloc
和MEM_RESERVE
2个内存的Gibibytes?
随着新元素的添加,新pages
(大约64K左右)会根据需要进行MEM_COMMIT
。当容器死亡时,内存将被VirtualFree
相应地释放。
出于好奇:
这技术上会有效吗?
是否有任何表现原因不这样做?
编辑:澄清:如果游戏中有10000个容器,那么<em>保留 2GiB * 10000内存 - 但提交的内存将小于2(或4)吉布。
那些10000个容器最多也可以是2 ^ 16个容器(或者地址空间允许的容量很多)。
答案 0 :(得分:1)
是的,可以使它工作。
当我玩它 1 时,我发现从相当大的内存块(例如,兆字节)开始,它仍然最好提交内存,然后跟随尺寸的几何级数。调用VirtualAlloc
(显然)需要切换到内核模式,因此如果你可以帮助它,你需要经常避免这样做。
虽然那是很久以前 - Windows NT 4或Win2K的时间框架,所以事情可能已经发生了变化。 功能