Hi all --

So, the overall discussion is about how to access the list of all processes to be used in tools such as the ProcessExplorer. We currently do this via "Process allSubInstances" to then filter the terminated ones. Then we put this again into a WeakArray and extract labels (for non-nil elements) for the tool.

While working on the multi-threaded OSVM, Leon noticed a slowdown during benchmarks whenever an existing ProcessBrowser was self-updating during the benchmark. While this depends on the current heap size, we were wondering whether there should be a faster way to get the list of processes like getting the list of classes for code-browsing tools.

The thing is that maintaining, for example, a WeakSet during process creation puts pressure on the GC, which might be annoying for process-intensive applications such as Tweak. Having 64-bit images already and once multi-threading is up and running for everybody, we are likely to observe a larger footprint for "Process allSubInstances" ...

... why #allSubInstances anyway? Who dares to subclass Process? :-)

Best,

Marcel

Am 28.03.2024 14:39:48 schrieb Marcel <marcel.taeumel@hpi.uni-potsdam.de>:

...instead of "Process allSubInstances". The caveat is this: process creation gets a little bit slower while accessing the list of runnable *and* waiting processes gets about 40x faster:

[ [] newProcess terminate ] bench.

AFTER: '140,000 per second. 7.13 microseconds per run. 35.02 % GC time.'

BEFORE: '224,000 per second. 4.47 microseconds per run. 4.38 % GC time.'

[ aProcessBrowser updateProcessList ] bench. -- allow quick updates

AFTER: '4,410 per second. 227 microseconds per run. 77.34453 % GC time.'

BEFORE: '118 per second. 8.47 milliseconds per run. 2.59792 % GC time.'

Why do we need this? If you have an auto-updating ProcessBrowser running in the background while doing time-sensitive benchmarks, you want a fast ProcessBrowser :-)

Please see the attached change set. Thanks to Leon and Eliot for the hint!

Best,

Marcel