我使用大型R对象，这些对象有时被我们本地网络上的多个人以只读方式访问。例如，引用类或R6 object可用于存储与特定模型相关的验证结果，并且它可能具有许多只读验证相关方法。我想继续使用R来维护工作流程的同质性，避免转向更适合解决我要问的问题的语言（如Java或Python）。
每次我们在新的R会话中需要它们时，不是重新实例化这些对象或从序列化输出中读取它们（例如，RDS或redis），保持活动R进程运行会更有效率在一些可在网络上访问的服务器上，然后将memcpy从该服务器上的对象转移到本地计算机上：某种准object pooling。注意，这些有时是合法的非表格R对象，例如很难转换为database-backed object（可能仍然较慢）。
我理解R维护堆上范围内的所有信息，因此如果不控制gc可能很难做到，但是可以在一个字节上“虹吸”远离其他R会话的对象 - 使用某种底层C魔法的字节级别？我不太了解R如何管理内存中的对象以了解如何执行此操作，但也许现有代码的包或片段可以提供灵感。
我也愿意穿上紧身衣并对上述对象进行限制，这些对象可以使这项任务变得更容易（例如，只能引用某些包，或者方法定义不能成为使这项任务无法完成的奇怪的闭包，或者甚至只能是S3对象。）
编辑：我刚才意识到我没有调查过RProtoBuf。那可能合适吗？
答案 0 :(得分：4)
执行此操作的标准方法是将对象序列化为可以在以后安全地加载到另一台计算机上的字节流。如果所有内容都在R中，那么base::serialize方法正是如此，如果需要在用其他语言编写的应用程序之间共享数据，那么RProtoBuf是什么。在任何一种情况下，您都可以将序列化字节写入RDS或redis或任何其他数据存储。
memcpy会出现问题。最根本的是，如果并非所有计算机都具有相同的字节顺序，则计算机之间的体系结构差异会导致此错误。此外，您必须找到一种方法将复杂数据结构表示为可在另一台机器上解释的字节流。也许事情被加载到不同地址的内存中，所以你不能指望做一个原始memcpy而不修复指向不同内存位置的指针，但是如果你这样做，你就是在进行序列化，所以为什么不再使用base::serialize或RProtoBuf。