Skip to content

FLIP: Execution effort calibration III#369

Open
janezpodhostnik wants to merge 2 commits into
mainfrom
janez/execution-effort-calibration-3
Open

FLIP: Execution effort calibration III#369
janezpodhostnik wants to merge 2 commits into
mainfrom
janez/execution-effort-calibration-3

Conversation

@janezpodhostnik

@janezpodhostnik janezpodhostnik commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

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

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@janezpodhostnik janezpodhostnik marked this pull request as ready for review June 11, 2026 13:41
@bluesign

Copy link
Copy Markdown
Collaborator

little strange with set_value and get_value, do you have any insight there?

@janezpodhostnik

Copy link
Copy Markdown
Contributor Author

Are you referring to the value change of them? @bluesign

@bluesign

Copy link
Copy Markdown
Collaborator

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.

@janezpodhostnik

Copy link
Copy Markdown
Contributor Author

Whats going on underneath is that setting also does a get, so the cost of a set is actually get+set.

@bluesign

bluesign commented Jun 23, 2026

Copy link
Copy Markdown
Collaborator

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
Writing new slab - > get (0) + set (data size) = set(data size) -> (set_cost-get_cost) * data_size -> not OK
Modifying existing slab -> get(old size) + set(new size) -> this may be not 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.

@janezpodhostnik

Copy link
Copy Markdown
Contributor Author

I suspect that most of the cost of set gets folded into individual atree operations.

get is generally more of an isolated operation, where as set leads to calls to other weights.

I will see if I can run an experiment for this, to make it somewhat more apparent whats going on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants