Re: JIT debugging (Attach and speed)

Yichao Yu <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <CAMvDr+S4pwdPwdRK71uwTqcCc5CoNHHsUuZQKAqbF4JG+y3Evg@mail.gmail.com>
> The prototype patch below (also in users/palves/jit-speedup, along
> with the attach fixes), simply delays computing a frame until
> it's necessary, and it cuts down the time for:

(The patch seems to have some white space breakage but the branch works great.)

>   gdb ---args ./testsuite/outputs/gdb.base/jit/jit-main ./testsuite/outputs/gdb.base/jit/jit-solib.so 2000
>
> from "takes too long so I canceled it" minutes, to around 2 seconds, for me.

There's indeed a huge improvement. The test I was using with ~2000 JIT
objects goes drops from ~400s to 7.5s (~3s without gdb). However a
rough scaling test suggests that the scaling is still ~O(n^2) 20k JIT
objects takes ~500s (~130s without gdb). It seems that the master was
actually super quadratic (if this is a word) when dealing with
multiple JIT objects.

> Having a pending breakpoint that is never resolved slows things down
> significantly again though...  The perf profile shows that breakpoint_re_set
> ends up calling parse_linespec which wants the selected block, which wants
> the selected frame, and then we're back at the same...  Maybe we
> could reconsider how pending breakpoints are re-parsed, and which
> context they're parsed in.  Not sure.
>
> Still, very promising.
>

Indeed. It's already so much better.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.