chore: manage call stacks using a tree #6791
Conversation
Peak Memory Sample
|
Compilation Sample
|
|
Looks like this is an improvement over #6747 and gets us closer to the optimal #6753 (comment) |
|
We are eating a performance penalty however. |
My guess is that it is due to getting a big list of flattened call stacks; not too deep but very wide, which means some elements have a lot of children and searching among them would be significant. I will try to use some sorted container for the children, like a btree. |
| @@ -85,6 +86,8 @@ impl Function { | |||
| /// Note that any parameters or attributes of the function must be manually added later. | |||
| pub(crate) fn new(name: String, id: FunctionId) -> Self { | |||
| let mut dfg = DataFlowGraph::default(); | |||
| // Adds root node for the location tree | |||
| dfg.add_location_to_root(Location::dummy()); | |||
There was a problem hiding this comment.
Is this something that could be done in DataFlowGraph::default() itself? Or maybe the new CallStackHelper?
Changes to Brillig bytecode sizes
🧾 Summary (10% most significant diffs)
Full diff report 👇
|
| .iter() | ||
| .rev() | ||
| .take(1000) |
There was a problem hiding this comment.
I assume we're searching in reverse so that we find recent additions faster; is there any significance as to why give up after 1000 children, after which a duplicate entry is acceptable? Is that value something that was actually observed?
I wonder if you thought some reverse index from e.g. the hash of the location to the child CallStackId could be used to make this faster and easier to reason about? Like children: HashMap<u64, CallStackId> where the key is fxhash::hash64(location).
Description
Problem*
Resolves #6603
Summary*
Call stacks are stored inside a big tree, which allows to share identical prefixes between call stacks
Additional Context
The only drawback is that we need to re-create the trees among function contexts during inlining
Documentation*
Check one:
PR Checklist*
cargo fmton default settings.