Cache call stacks when profiling Brillig execution

[vezenovm]

Problem

We have a call stack (which is a Vec<OpcodeLocation>) associated with every execution sample. Execution samples most likely have lots of repeated call stacks especially as we profile a loop heavy programs.

Happy Case

Each OpcodeLocation::Brillig consists of two usizes. We can build a cache for call stacks that we pass separately to the flamegraph generator. Each call stack would have an index associated with it and then the execution profiling sample would store the index into the call stack cache rather than the entire call stack.

Workaround

Yes

Workaround Description

More memory

Additional Context

No response

Project Impact

Nice-to-have

Blocker Context

Profiling large programs can require massive amounts of memory

Would you like to submit a PR for this Issue?

None

Support Needs

No response

[jfecher]

Could also use im::Vector to take advantage of a type that is meant to be shared