我正在组织一个 NLP 实验，其中概念是系统中的代理，旨在产生由新概念组成的 Emergent 属性（here's a link 用于那些不知道 Emergence 是什么的人）。 Smalltalk（特别是 Pharo 方言）似乎是此类应用程序的理想选择，因为我可以轻松创建完全封装的概念对象，这些对象作为独立代理相互关联，而且 SmallTalk 允许我检查系统运行时的状态。
我担心的是，如果存在太多对象并且所有对象都相互发送消息，系统是否会开始阻塞。从理论上讲，我的实现可能会产生数百万个概念对象，如果系统无法处理那么大的事情，我不想花时间在 SmallTalk 中解决这个问题。
是否存在限制因素（软件因素，而非硬件） 关于 SmallTalk 图像中活动对象的数量？
系统能否处理可能出现的消息流量 在一个拥有数百万个健谈对象的系统中？
提前感谢您的帮助！
【问题讨论】：
我相信 Pharo 中对象指针的内部工作大小仍然是 32 位。 64b 版本一直在讨论，但在 64b 机器上运行 32b 虚拟机是一回事，而拥有真正的 64b 虚拟机又是另一回事。
所以那里有一个隐含的限制，但仍有“数百万”个对象的空间。开始达到“100 的数百万”，您很可能会遇到一些限制。
最终拥有数百万个对象并不是真正的问题，现在它转移到了控制线程，而在这种情况下，Pharo 并没有做太多的线程。因此，真正的问题在于您将拥有多少实际不同的上下文，而不一定是对象本身。
让数百万个对象相互通信并不是什么大问题，您只会遇到底层 VM 中存在的任何消息传递开销来限制原始性能。 Pharo 非常快，但它不是 Java 快。是否足够快由您来回答。
我也无法谈论 Pharo GC 处理数百万个活动对象的能力，我只能建议它是 2013 年，Squeak（Pharo 所基于的）自 90 年代中期就已经存在，GC 技术差不多现在成熟了，我不怀疑Pharo的GC在这方面非常糟糕。
我会简单地做一些微基准测试并自己尝试。
【讨论】：
关于 1：对象的数量受 VM 可用的虚拟地址空间的限制 - 在标准构建中，它只有几百 MB 大。我当前的 Squeak 图像包含超过 350 万个处于空闲状态的 Object 实例 - 这应该让您对可能发生的事情有个印象。
关于 2：我的 Squeak 图像在我不是那么最新的 Intel Core i7 2620M（当然只使用一个内核）上每秒发送大约 2600 万条消息。
但是，我怀疑您是否会对当前方法的结果感到满意。你谈到了检查系统的状态——这在 Squeak/Pharo 中真的很棒——但你不能（手动）检查数百万个对象的状态。但是话又说回来，我不知道你到底在做什么；）
【讨论】：