Re: [delayed-symfile] [commit] Fix a regression on delayed retrieving of the unwinding debug info.

[Tom Tromey <tromey@redhat.com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> Disputable is whether the delayed reading of partial symtabs and
Jan> unwind info should not be split in half and read separately on
Jan> their specific demand.  Assuming their current load together has
Jan> been decided for the GDB code simplicity and it has no real
Jan> performance impact.

It might not be as deep as that.  Maybe nobody ever looked at this
idea before :-)

I occasionally think that in the future we will end up redoing all the
symbol table and dwarf parsing stuff to be much more incremental.  But
I think this is probably still a lower priority than fixing all the
C++ problems.  And, maybe we'll never really feel the need, I don't
know.

[ type lookup patch ]
Jan> Assuming (did not measure it so far) this patch will nullify any
Jan> performance effect of this archer-tromey-delayed-symfile branch.

I think we'll still see decent benefits in some scenarios.

My canonical test case concerns two things: first, "attach"
performance, and second, "bt" performance.  I do this by running OO.o
Writer (with all debuginfo installed) and then attaching to it; then I
run "thread apply all bt full".

The "attach" part shows us the biggest benefit; I think your patch
won't affect that.  The second thing helps quantify the slowdown
during a typical operation; it also lets us see whether incremental
reading is really working; that is, if you do both of these things
with -batch, you can measure performance gained by not reading some
objfiles.

I'm still interested to hear your results.


I'm very happy that you fixed these bugs, but I also wanted to address
a couple process things here.

I know you have limited time to work on your own major patches, so if
you find bugs like this, feel free to just push them back to the
branch author for fixing.  It is ok to do this publicly.  If the
branch author can't get to the bug in a timely way, we can work
something out.

It is also ok by me if you also want to just fix the bugs like you did
this time.  I just want to make sure that you don't feel trapped into
doing this.


The other process thing is that I obviously made a mess of this
branch.  I must have not run the test suite, or something careless
like that.  I think we need to go back to our original plan of patch
review for everybody.  Let's discuss exactly how to do this, and when
in the process.

Tom