我正在整理一個NLP實驗，其中的概念是在一個系統中的代理人，這個系統被設計用來產生由新概念組成的Emergent屬性（here's a link，那些不知道Emergence是什麼的人）。 Smalltalk（特別是Pharo方言）似乎是這類應用程序的理想選擇，因爲我可以輕鬆創建完全封裝的概念對象，這些對象作爲獨立的代理相互關聯，並且，SmallTalk允許我檢查系統運行時的狀態。Smalltalk圖片中的對象數量是否有上限？
我的問題是如果有太多的對象存在並且所有的消息都發送到另一個，系統是否會開始窒息。從理論上講，我的實現可能會產生數百萬個概念對象，如果系統無法處理大量的事情，我不希望在SmallTalk中花費這麼多時間。
是否有限制活動對象的在Smalltalk的圖像數量的因素（軟件因素，不是硬件） ？
系統可以處理在具有數百萬個聊天對象的系統中會出現的消息流量 嗎？
非常感謝您的幫助！
Pharo中對象指針的內部工作大小仍然是32位，我相信。有64b版本的喋喋不休，但在64b計算機上運行32b虛擬機是一回事，另一件事是通過虛擬機實現64b。
因此，存在一個隱含的限制，但仍有「數百萬」對象的空間。開始接近「百萬的數百人」，你可能會碰到一些限制。
最終擁有數百萬個對象並不是一個真正的問題，現在它轉向了控制線程，而Pharo在這種情況下並沒有做太多的線程處理。所以它實際上是如何有多少實際的不同情境，你會有，不一定是對象本身。有一個數以百萬計的對象相互交談的鏈並不是什麼大不了的事，你只需運行底層虛擬機中的任何消息傳遞開銷，以限制原始性能。 Pharo速度非常快，但Java並不快。對於你來說速度是否足夠讓你回答。
我也不能說Pharo GC如何處理數百萬個活物，我只能建議它是2013年，自90年代中期以來Squeak（基於Pharo基礎）已經存在，GC技術很漂亮現在已經很成熟了，而且我並不認爲Pharo的GC在這方面顯得非常糟糕。
我會簡單地做一些微型基準測試，併爲自己嘗試。
關於1：對象的數量受VM可用的虛擬地址空間的限制 - 使用標準構建，其大小僅爲幾百MB。我目前的Squeak圖片包含超過350萬個處於空閒狀態的Object實例 - 這應該會給您一個什麼可能的印象。
關於2：我的吱吱聲圖像在我不是最新的英特爾酷睿i7 2620M上每秒發送約26百萬條消息（當然，只使用一個內核）。
但是，我懷疑你會滿意你當前的方法的結果。你談到了檢查系統狀態 - Squeak/Pharo確實非常棒 - 但是你不能（手動）檢查數百萬個對象的狀態。但是我再也不知道你在做什麼了;）
噸/年以及跳這個這麼快！僅供參考 - 我不打算一次檢查所有對象 - 但我確實需要檢查概念結構（概念可以自我複製，產生更復雜的表單，但它們仍然連接在一起），以查看正在做什麼，如何它正在被製造，是什麼造成了它。只要我能做到這一點，我就是GTG。 –
w00t - t/y快速回復！ –