是否有人对自定义数据（delphi集合，二叉树，DIContainers等）的存储和处理有任何建议（产品，工具集，方法或其他），这些数据不限于标准的win32内存地址空间？为了实现这一目标，是否有任何现成的东西可以相当于持有10GB的TList，从而吹掉/ 3GB的开关屏障和4GB的Windows窗口限制？
我们理想需要的是对Delphi应用程序员非常透明的东西，但允许非常快速地访问其结构中保存的数据，最好是通过键查找。相当于delphi集合容器就可以了，但它的内存使用需要通过AWE。它还需要注意映射和取消映射它所使用的物理空间到win32进程中使用它，即那将是transpprent位......
将数据移动到数据库中并不是答案 - 信息需要保持驻留内存以便快速访问。我们尝试过的内存数据库/表没有使用AWE，访问速度也很慢。我们当前的Delphi数据结构很好，但是会限制win32地址空间的限制。
答案 0 :(得分：2)
我将成为一个完整的笨蛋，告诉你我已经做了比你正在描述的更先进的东西......在工作中。所以这都是我所害怕的封闭源头。在任何地方都没见过这样的东西我们将VM，AWE，MMF和（很快）32 64位IPC组合成一台大型平均数据处理机器，可处理高达64 GB的内存，同时处理数百个数据集，每个数十GB / em>的
但我可以给你一些提示：AWE视图交换相当慢，因为它在交换期间强制暂停所有正在运行的线程。因此，明智地选择你的窗口大小（越小，交换越快 - 但随着规模越大，呼叫开销越低）。我们已经确定了AWE视图大小等于Windows默认页面大小（4 KB），但这只是因为随机访问以这种方式表现最佳。 Lineair数据访问可以通过更大的视图大小运行得更快。
每个视图都可以映射到已分配的AWE内存的任何部分，因此可以帮助的一件事就是只将这些页面映射到需要访问的视图中 - 并尝试保存在非必要的视图交换（优先级队列）上浮现在脑海中）。
此外，在您的设计中应该有一个注册机制来处理视图和后面的AWE内存之间的链接。这最好是线程安全的！
至于一般用法：不，这不适合常规的Delphi类。您应该完全切换到另一个概念 - 并将数据结构基于此。
无论如何，祝你好运！你需要它......; - ）
答案 1 :(得分：0)
有system calls可以执行此操作，但并非所有版本的Windows都支持它（特别是Windows XP不支持AWE）。
由于API无法返回指向对象的指针，因此透明度将成为一个问题。将超过4GB的RAM映射到4GB的地址空间意味着32位指针可能不明确 - 您可能会将不同的对象映射到同一位置。
这种歧义意味着您必须为包含可用于访问“记录”的句柄的对象生成代理。某些SQL Server版本使用此技术将磁盘缓冲区存储在AWE内存中。像这样的方法可能适用于矩阵中的行，其中操作在整行上完成。更精细的访问将更加繁琐。
为了提供对映射对象的直接访问，您必须实现一个协议，其中指向映射内存的临时指针可用。这也需要在使用时将对象锁定在内存中 - 再次，bang会提高透明度。
假设您现在可以获得64位版本的Delphi，那么对于需要更多RAM的客户而言，最好不要使用64位版本的Windows。
答案 2 :(得分：0)
您声明您不想迁移到数据库，但是数据库that specifically uses AWE呢？
我没有亲自试过，但会考虑将这家公司的产品用于我自己的项目。
[编辑]：NexusDB是Delphi友好的：它起源于旧的Turbopower FlashFiler开发（但从那时起已经走了很长的路）。
答案 3 :(得分：0)
AWE的问题与旧的基于DOS的EMS和XMS非常相似 - 如果你曾经使用它们的话。基本上，保留一系列可寻址存储器，然后在可寻址范围之外的存储器在需要时映射到可寻址范围，并且在不再需要时不映射，允许其他存储器映射在相同地址。因此，大多数非AWE感知数据结构或容器在这种情况下不起作用 - 可能TMemoryStream后代更容易构建。构建一个将数据存储在AWE内存中的TList等应该很容易，它应该跟踪数据的真正存储位置，并在需要时调用它们，在数据映射到可寻址内存时调整地址。我不知道任何使用AWE的Delphi容器库，还有另一个问题：桌面32位操作系统不能使用超过4GB的物理 RAM，需要服务器版本，以及支持的物理RAM取决于所使用的版本，请参阅here以获取完整列表。
答案 4 :(得分：0)
假设数据一次性加载并适合可用内存，NexusDB AWE将非常快。数据库可以创建为仅内存的数据库，在操作时不需要任何进一步的硬盘访问。
答案 5 :(得分：0)
听起来像你们可能会考虑放弃当前的数据库SQL后端并转向100％NexusDB + AWE解决方案。
（或者更确切地说，放弃对SQL后端的日常访问，并具有导出/同步功能，可以将任何所需的NexusDB报告数据写出到MSSQL报告数据库。）
w ^
答案 6 :(得分：0)
您的情况与我们的情况类似，我们的应用程序使用一个巨大的数据文件存储在内存映射文件中。文件大约750MB，我们从它们分配数据结构，使用高达1.5GB的RAM。
我们发现没有解决4GB限制的问题，除了将其中一部分移到FPC / Lazarus之前，不幸的是Delphi是64位。 AWE不适用于Vista Home版本，我们也无法使用MMF。
您可以使用滑动窗口尝试内存映射文件，这意味着您可以根据应用程序使用的部分动态创建文件的不同块的视图。这听起来不会起作用，因为你需要在内存中同时使用整个文件。