Stop querying for stack frames multiple times on CallerInfo()

[mikeauclair]

Summary

• Switches CallerInfo to use runtime.Callers() to pull the stack instead of repeatedly calling runtime.Caller()

Changes

• Switch to a single call of Callers() instead of repeated Caller invocations
• Create a slice with cap 50 to store the frame pointers (Zero percent married to this value)
• Iterate over the frames with the frames.Next() iterator

Motivation

• We heavily use mocks at DevotedHealth and the repeated calls to pull the stack were flagging as a contributor when I profiled some of our slow tests - see example of Caller contributing a CPU cost of 7660ms out of a total cost of 13740ms

Related issues

[dchang-dchang]

I'm ok with 50. It would be nice if n==50 that we added a "more callers ignored" or something as the last "caller" just as a warning to users.

[mikeauclair]

I'm ok with 50. It would be nice if n==50 that we added a "more callers ignored" or something as the last "caller" just as a warning to users.

That totally makes sense - let me see if I can figure out how to actually test that before I commit to adding it, though

[dchang-dchang]

I didn't realize what repo I was in - this is also fine to panic as this will be all tests

[dchang-dchang]

and if you're going to upstream this change, presumably, they'd like a version where you loop and get all of them as the previous version does - just 10-50 at a time

[mikeauclair]

and if you're going to upstream this change, presumably, they'd like a version where you loop and get all of them as the previous version does - just 10-50 at a time

Yeah I think I'm actually just going to do that now that I think about it

[dchang-dchang]

Looks good! A small nit - I think it's marginally easier to read and marginally less instructions but I'm good either way.

(would be nice to have a test to prove that it works for bigger stack depths - not sure if that's easy to do or hard?)

[dchang-dchang]

nit: maybeMore := n == stackFrameBufferSize and you can tuck it behind the n==0 early return a couple lines down

[dchang-dchang]

same nit here

[mikeauclair]

(would be nice to have a test to prove that it works for bigger stack depths - not sure if that's easy to do or hard?)

It's hard because they explicitly opt stack frames from the testify packages out of accumulation 🙃