有没有人对自定义数据(delphi集合,二叉树,DIContainers等)的存储和处理有任何建议(产品,工具集,方法或其他),这些数据不限于标准的win32内存地址空间？为了把它放在极端,是否有任何现成的东西可以相当于持有一个10GB的TList,从而吹出/ 3GB的开关屏障和4GB的
Windows窗口限制？

理想情况下,我们需要的是Delphi应用程序员非常透明的东西,但允许非常快速地访问其结构中保存的数据,最好是通过密钥查找.相当于delphi集合容器就可以了,但它的内存使用需要通过AWE.它还需要处理映射和取消映射它使用的物理空间到win32进程中使用它,即那将是transaprent位…

将数据移动到数据库中并不是答案 – 信息需要保持驻留内存以便快速访问.我们尝试过的内存数据库/表没有使用AWE,访问速度也很慢.我们当前的Delphi数据结构很好,但是会限制win32地址空间的限制.

最佳答案 我将成为一个完整的笨蛋,告诉你我已经做了比你正在描述的更先进的东西……在工作中.所以这都是我所害怕的封闭源头.在任何地方都没见过这样的东西我们将VM,AWE,MMF和(很快)32 64位IPC组合到一台大型平均数据处理机器中,可处理高达64 GB的内存,同时处理数百个数据集,每个数据集数十GB.

但是我可以给你一些提示：AWE视图交换相当慢,因为它在交换期间强制暂停所有正在运行的线程.因此,明智地选择你的窗口大小(越小,交换越快 – 但随着规模越大,呼叫开销越低).我们已经确定了AWE视图大小等于Windows默认页面大小(4 KB),但这只是因为随机访问以这种方式表现最佳. Lineair数据访问可以通过更大的视图大小运行得更快.

每个视图都可以映射到分配的AWE内存的任何部分,因此可以帮助的一件事就是只将那些页面映射到需要访问的视图中 – 并尝试保存在不合适的视图交换上(优先级队列会浮现在脑海中) ).

此外,在您的设计中某处应该有一个注册机制来处理视图和后面的AWE内存之间的链接.而这最好是线程安全的！

至于一般用法：不,这不适合常规的Delphi类.您应该完全切换到另一个概念 – 并将数据结构基于此.

无论如何,祝你好运！你需要它…… 😉