|
3 | 3 | ## Performance |
4 | 4 |
|
5 | 5 | * The pre-validation of the cluster worker allotted to a future when |
6 | | - launched was unnecessarily expensive due to a thinko, e.g. it would |
7 | | - take ~0.1-0.2 seconds for a multisession future, whereas after the |
8 | | - fix it is effectly 0.0 seconds. |
| 6 | + launched was unnecessarily expensive due to a thinko since |
| 7 | + **future** 1.40.0 (2025-04-10), e.g. it would take ~0.1-0.2 seconds |
| 8 | + for a multisession future, whereas after the fix it is effectly 0.0 |
| 9 | + seconds. |
9 | 10 |
|
10 | | - * Cluster and multisession workers initiates more things when |
11 | | - created, e.g. pre-loading of packages and memoization of available |
12 | | - cores. Previously, such steps were performed only when the first |
13 | | - future was evaluated on a worker. |
14 | | - |
15 | | - * The **future** package is now pre-loaded on the parallel workers as |
16 | | - soon as a new cluster or multisession future backend is set |
17 | | - up. Previously, it was loaded with the first future being evaluated |
18 | | - on a worker. |
19 | | - |
20 | 11 | * Calling `resolved()` on a lazy `ClusterFuture` would collect the |
21 | 12 | result for the first _resolved_ future in order to free up one |
22 | 13 | worker slot. Now this is only done if all slots are occupied. The |
23 | 14 | net benefit is that lazy cluster futures will be launched faster, |
24 | 15 | unless all workers are busy. |
25 | 16 |
|
| 17 | + * Cluster and multisession workers initiates more things when |
| 18 | + created, e.g. pre-loading of packages and memoization of available |
| 19 | + cores. Previously, such steps were performed only when the first |
| 20 | + future was evaluated on a worker. |
| 21 | + |
26 | 22 | ## Bug Fixes |
27 | 23 |
|
28 | 24 | * Calls to `resolved()` were not registered by FutureJournal. |
|
0 commit comments