寻找一种加速读取和处理大型文本文件的方法（基本上是csv; stream_lf）。
我应该绕过RMS吗？解决方案可以是异步或同步的。
当前的实现是同步的，但速度太慢。
实施在HP Pascal中，并使用pascal运行时库（OPEN / READLN / EOF / CLOSE）。绕过pascal运行时库是可以接受的。
示例可以是C或Pascal。
答案 0 :(得分：3)
对于seqeuntial文件：查看WASD或VWCMS代码（查看http://www.vsm.co.au/wasd）。我知道这些绕过RMS也支持Web服务的速度，但我不知道在whar源代码中已经完成了。 对于相关文件，请考虑序列。记录可能是非现实的（空？） 对于索引文件：请勿。使用RMS代替，因为内部结构（索引与这些文件中的数据交织在一起。在新的/重新安排的文件中，没关系，但缺少维护会导致RMS外部访问出现问题）
答案 1 :(得分：1)
你知道一个事实，即RMS正在减慢你的速度吗？
将您的处理时间（IO，CPU，Elapsed）与SEARCH / STAT / WIN = 0进行比较 一个指示可能是低USER模式，高EXEC，高IDLE。 使用MONI MODE或GETJPI与EXECTIM，USERTIM
通过PASRTL或直接读取最佳RMS可能意味着几个大型缓冲区，具有预读，无共享或只读共享。
重试后：$ SET / RMS / BLO = 127 / BUF = 8！ $！对于最近的OpenVMS版本（8.4或8.3 +补丁），块= 255或128
如果有许多小记录，并且EXEC模式很高，则可能有太多时间进出RMS来提取记录。在这种情况下，请尝试使用C或COBOL来读取非共享文件。两者的RTL（运行时库）将使用BLOCKIO，而不是记录IO以避免RMS开销。他们仍然尊重上面提到的RMS缓冲设置。尝试？
祝你好运......让我们知道你的表现如何？ 一些前/后数字也许。干杯， 海因
答案 2 :(得分：1)
对于系统块设置为32.我尝试了SET RMS / BLOCK = 32 / BUF = 8。这已经有所改善。
[编辑：如果没有进程设置，则系统设置我们使用。所以完成的测试增加了缓冲区，但没有使它们更大]
32只有16KB。伟大的1992年，2012年的跛脚。 如果更多的缓冲区已经有所帮助，那么更大的缓冲区可能会帮助更多。 越大越好。 8KB的倍数可能只是一个额外的帮助。 因此尝试128，并且还在SET RMS进程级别尝试255。 如果它带来快乐，那么您可能希望调整过程以选择自己的RMS设置而不依赖于DCL设置。
RMS $ GET调用通常只会获得一条记录， 但你可以“撒谎”文件，SET FIL / ATTR =（RFM = UDF）或者（RFM = FIX，LRL = 8192）。您可以使用SYS $ MODIFY在程序中临时执行此操作。 之后你可以读大块但你的程序需要解码欺骗记录中的真实记录。 这将非常类似于使用SYS $ READ / SYS $ QIOW（BlockIO），但坚持记录模式将为您提供免费的“预读”。是的，你可以用aysnc IO编写自己的代码，但这很麻烦。
顺便说一下......不要对缓冲区的数量感到疯狂。 在基准测试中（很多年前），我看到超过10个左右的好处或消极的好处。 原因是RMS确实“预读”但不“保持领先”。它异步填充所有缓冲区，但随着缓冲区的处理，不会发布额外的读取。只有当所有数据都被消耗时，才会为所有缓冲区重新发出IO，而不是在处理缓冲区时尝试保持领先。那些“浪潮”的IO可能会混淆存储子系统，波浪中的第一个IO可能会被其余波段减慢......所以程序会等待。
有多少数据在播放？几十兆字节或千兆字节> XFC缓存是否会在导出和处理之间进行缓存？
遇见vriendelijke groetjes。 海因。
答案 3 :(得分：1)
使用C. 绕过RMS。
fopen 该文件。
fseek 结束。
ftell 获取文件大小
malloc 一块大小
的内存fread 一气呵成。
有人可能怀疑你的文件是否比你的工作集大很多，分页可能就是吃你的挂钟。