Optimize computation and memory usage by replace indexmap

[howjmay]

Description

BuilderArg is not necessary for the current codebase. It introduces extra wasted computation, and occupied more spaces. We can replace it with IndexSet of CallArg

Test plan

I ran the sui-types tests already

---

Release notes

Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.

For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

• [ ] Protocol:
• [ ] Nodes (Validators and Full nodes):
• [ ] Indexer:
• [ ] JSON-RPC:
• [ ] GraphQL:
• [ ] CLI:
• [x] Rust SDK:

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
sui-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 23, 2024 9:10pm

[vercel[bot]]

@howjmay is attempting to deploy a commit to the Mysten Labs Team on Vercel.

A member of the Team first needs to authorize it.

[howjmay]

Thank you @amnn and @tnowacki Sorry for misunderstanding the behavior here, and opened the PR. Maybe I can amend this PR into adding the explanation that @tnowacki you wrote. The current comment of force_separate_pure() is not that clear for me.

One thing I am still confused about the above example is

once they are used mutably the type is fixed and they cannot be recast, even if the bytes are the same. I thought the types of vectors have to be decided when they are passed. I am confused about how can we recast the types here.

[amnn]

Hi @howjmay, yes that is indeed a good idea!

Regarding your question: yes, the type of a given vector in Move or from a PTB MakeMoveVec command is fixed and cannot be recast, but a Pure Input is just bytes, so in cases where those bytes are not used mutably in the PTB, they can be used to represent multiple types (for example the bytes of a u64 could also represent two u32s).

The use of an IndexMap with a Pure key ensures that immutable usages with the same bytes do get deduplicated, while the other Pure key ensures that they don't.

Perhaps in addition to adding the comment, you could also update the names of the enum variants used as keys to the IndexMap to make it clear that one is for mutable Pure inputs (PureMut?) and one is for immutable (Pure or PureImmut)? Thoughts @tnowacki ?