
| > Stephen Pitts
wrote: | >> Is there an easy way to profile stack usage without rebuilding with | >> ticky-ticky profiling? I have two implementations of an algorithm; | >> the one with straight lists seems to use constant stack, while the | >> one with a JoinList is eating up stack at an O(n) rate. I don't think there is right now. What sort of profile would you like to see in an ideal world? What sort of profile would still be useful, even if not ideal? Remember that GHC is a concurrent system, so there may be many threads running, each with its own stack.
Even with ticky-ticky, I'm not sure if we capture maximum stack depth at the moment. But I agree that something along those lines sounds useful.
Anyone feel like helping implement it, if we could agree a spec?
In the CVS version there's a -xt RTS flag that enables inclusion of thread stacks in a heap profile. It's crude, because thread stacks grow by doubling their size every time they run out of space, but it should be enough to show the difference between O(n) stack usage and O(1). Cheers, Simon