Looking at:
commit 36a7c5f2c3b44f5556fc2a8e05051211b0e3d834 Author: Henrik Grubbstr<C3><B6>m (Grubba) grubba@grubba.org Date: Wed Aug 26 17:44:39 2020 +0200
Concurrent.Promise: Refactored the dependency handling.
I find:
- final int _materialised; - final AggregateState _astate; + protected array(mapping(int:mixed)) dependency_results = ({ ([]), ([]) }); + protected int(0..) num_dependencies; + protected int(1bit) started; + protected int(0..) min_failure_threshold; + protected int(-1..) max_failure_threshold; + protected function(mixed, mixed, mixed ... : mixed) fold_fun; + protected array(mixed) extra_fold_args;
If you are running a system with a huge number of promises, it thus causes a substantially increased memory footprint. The reason I used the _astate and _materialised variables was because it allows the memory footprint to be substantially lower after the promise has been setup.
In systems with lots of long-lived promises running around, the memory footprint of a single promise seems quite relevant.
Stephen R. van den Berg wrote:
commit 36a7c5f2c3b44f5556fc2a8e05051211b0e3d834 Author: Henrik Grubbstr<C3><B6>m (Grubba) grubba@grubba.org Date: Wed Aug 26 17:44:39 2020 +0200
Concurrent.Promise: Refactored the dependency handling.
In systems with lots of long-lived promises running around, the memory footprint of a single promise seems quite relevant.
Grubba, did you consider this when implementing the refactoring?
pike-devel@lists.lysator.liu.se