Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
manipulating_tables_and_lookup_tables [2026/07/25 04:25] hermann |
manipulating_tables_and_lookup_tables [2026/07/25 04:29] (current) hermann |
||
|---|---|---|---|
| Line 333: | Line 333: | ||
| </code> | </code> | ||
| - | > **Note:** This is also why ''accumulated'' should never be read again after ''AddTableRow'' consumes it in the same iteration. When exactly one reference to a table's current version remains, Dinamica can update it destructively — modifying the existing storage in place. A second live reference to ''accumulated'' (reading it directly somewhere else, instead of only through ''nextAccumulated'') forces Dinamica to copy the table instead, since the old version now has to stay intact for that other reference. That copy cost repeats every iteration. | + | > **Note:** This is also why ''accumulated'' should never be read again after ''AddTableRow'' consumes it in the same iteration. When exactly one reference to a table's current version remains, Dinamica can update it destructively — modifying the existing storage in place. A second live reference to ''accumulated'' (reading it directly somewhere else, instead of only through ''nextAccumulated'') forces Dinamica to copy the table instead, since the old version now has to stay intact for that other reference. That copy cost repeats every iteration — see [[basic_data_flow|Basic Data Flow]] for this same rule stated generally, beyond just tables. |
| **Why this isn't the best approach.** [[basic_data_flow|Basic Data Flow]] documents three conditions under which a loop's iterations can run simultaneously: no mux directly inside the loop, nothing produced inside the loop consumed outside it, and no loop member used as a submodel's output port. A mux-based accumulator like the one above breaks the first condition outright — the mux ties every iteration to the one before it, so the loop can never run as anything but sequential, even when the per-iteration work is otherwise completely independent, as it is above (each row's value depends only on that row's own key). | **Why this isn't the best approach.** [[basic_data_flow|Basic Data Flow]] documents three conditions under which a loop's iterations can run simultaneously: no mux directly inside the loop, nothing produced inside the loop consumed outside it, and no loop member used as a submodel's output port. A mux-based accumulator like the one above breaks the first condition outright — the mux ties every iteration to the one before it, so the loop can never run as anything but sequential, even when the per-iteration work is otherwise completely independent, as it is above (each row's value depends only on that row's own key). | ||