Re: More info on PR/9711 (quadratic slowdown for deep stack traces)

Paul Pluzhnikov
2009-09-02T03:42:11Z

On Tue, Sep 1, 2009 at 1:48 PM, Joel Brobecker<brobecker@adacore.com> wrote:

> Taking a step back, it does not feel like this is actually a super
> common issue. For this to happen, we need a program such that we get
> a really deep stack (with 1000 iterations, it takes 1.5 secs before
> my change, about 0.5 sec after IIRC), and a register that does not
> get saved throughout the entire stack. Since we still end up printing
> the correct value at the end, is it worth enhancing the design to
> handle this case?

It's been almost a year since I filed this PR, so am hazy on details :-(

AFAIR, the real problem showed up while debugging GDB itself, when I
made it go into infinite recursion loop. Making programs spin into the
ground via infinite recursion is not that uncommon (IMHO) and when
that happens, you do get 100_000 or more frames, and usually you only
care about the outermost 10 of so. It is quite annoying if GDB takes
several minutes to tell you what these 10 interesting frames are.

Cheers,
--
Paul Pluzhnikov