fix(core): keep MAST merge from growing stripped forests#3044
fix(core): keep MAST merge from growing stripped forests#3044huitseeker wants to merge 5 commits intonextfrom
Conversation
0bc8f93 to
ad3d1d8
Compare
bitwalker
left a comment
There was a problem hiding this comment.
LGTM! Ping me for a re-review after this is marked ready (if needed)
greenhat
left a comment
There was a problem hiding this comment.
LGTM! Thank you for a prompt response!
ad3d1d8 to
22c04a7
Compare
|
@huitseeker Maybe we should apply this to |
22c04a7 to
2e4ff55
Compare
|
@bitwalker Is this a blocker for something? The improvements in serialization size from this fix are in the low single-digit percentages. I agree there is no semver issue, but I am not sure if it's worth the trouble. |
|
We were observing double-digit reduction in size due to compaction previously on some of our example programs (e.g. 18k -> 13k in one of them), but obviously that can vary significantly. In any case, without compaction, it's a lot easier to hit the account/note code size limits when compiling Rust programs - so it's not a blocker for some feature, but it does directly impact whether Rust components that run up against the limit will be usable or not. Since users won't get stuff in Since we also have at least one other fix queued up in |
This fixes a case where
MastForest::compact()could make a stripped forest larger instead of smaller.The root cause is twofold. First, merge rebuilt basic blocks from the padded operation iterator, so padding ops became "organic" serialized ops. Second, after debug info was cleared, compact still wrote empty node decorator rows for every merged node.
The fix keeps the original basic-block batches during merge and skips empty node decorator rows. The op decorator CSR is still kept as a valid empty structure after debug info is cleared.
Closes #3035.