New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delete im #585
Conversation
b147557
to
45c251b
Compare
Is it happening? |
@leighmcculloch I believe so, if you would be inclined to review! I have pushed a rebase and it should be ready now. (It'd be good to do soonish since I will be out after thursday, and this will bitrot fairly quickly) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Half way through my review, will continue tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏻. My knowledge of some of the intricacies is limited now so I think this should probably get an ✅ from another person, but it looks good to me overall.
This still has some TODOs in the form of error codes to consolidate/reassign, but the code is otherwise I think as it should be.
This PR deletes the
im
library previously backing theHost
collection objects (maps and vecs), and also reworks the comparison system to avoid #579. It replaces both vecs and maps with simple eagerly-copiedstd::Vec
s (maps are sortedstd::Vec<(K,V)>
s). It also eliminates all theWeakHost
andEnvVal
usage in theHost
; with a little more work plus catching up the SDK it should be possible to removeEnvVal
entirely. In addition to removingWeakHost
it also removes all the auxiliary pointers toBudget
stored in "metered" host objects; a singleBudget
and/orHost
is passed in to each operation that needs it.The only odd part of this is that maps and vecs no longer "share substructure" via the BTree/RRB code in
im
-- every edit makes a full copy -- but some consideration suggests this probably isn't a huge issue:RawVal
s, so are still "shallow" in that sense (and the storage map entries are changed fromBox
toRc
, so cloning them is "shallow" now too).im
would be holding everything in a single BTree or RRB node anyways, which means this is no less efficient. The sharing only kicked in on larger structures, and ... we're likely not going to have big maps or vecs available to users.EnvVal
(which used to comprise the map and vec entries) the data consumption actually shrinks with this change (again so long as you're dealing with small maps or vecs).Comments welcome!