FLIP: Execution effort calibration III#369
Conversation
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
little strange with set_value and get_value, do you have any insight there? |
|
Are you referring to the value change of them? @bluesign |
|
Yeah set being cheaper then get vs existing behaviour ( opposite ) I think some caching behavior etc can be in play, but if not seems little strange reading being more expensive than writing. |
|
Whats going on underneath is that setting also does a get, so the cost of a set is actually get+set. |
Yeah but now isn't get is much more expensive than set? With new weights. That little confused me I understand the point a bit, if there is existing data, set can be like delta ( set-get cost ) , but is it common case? Deleting slab -> get(old size) OK It feels like we are undermetering new slab writes with this logic somehow. ( putting cost to get instead ) Probably nothing so major btw ( as we also block flow for storage fees ) , just at first sight felt little weird. |
|
I suspect that most of the cost of
I will see if I can run an experiment for this, to make it somewhat more apparent whats going on. |
Proposes an update to Flow's per-kind execution-effort weights — the successor to FLIP-346: Execution Effort Calibration II.
Recalibrates the weights for FVM and runtime changes since FLIP-346, using a joint non-negative least-squares fit against the live mainnet scrape (3.39M user transactions) and the migrationtestnet synthetic-load scrape (0.22M labelled transactions). The proposed fit lifts mainnet per-transaction R² from 0.15 to 0.80.
FLIP file:
protocol/20260611-execution-effort-3.md