This content has been marked as final. Show 2 replies
The well-known method is to use the built-in ustackdepth as a tracker against multiple calls on a function by the same thread.
The usual issue with profiling recursion, as I understand it, is whether you want the total time a recursion takes, or you want the unit time of each call. In the former case, you might get a kachina-doll effect of longer call times on one function that includes the timing of N subsequent calls to itself. In the latter case, you lose sight of the nesting, which could be a valuable context, given the right case.
Are you trying to achieve one or both goals?
I would want to be able to do both. I suppose that initially, it would be good to see how much recursion is actually taking place and where the main delays are found.