From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7258 invoked by alias); 25 Feb 2009 01:47:36 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 7240 invoked by uid 22791); 25 Feb 2009 01:47:34 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_21,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org To: Jan Kratochvil Cc: archer@sourceware.org Subject: Re: [delayed-symfile] [commit] Fix a regression on delayed retrieving of the unwinding debug info. References: <20090224231429.GC23254@host0.dyn.jankratochvil.net> From: Tom Tromey Reply-To: Tom Tromey Date: Wed, 25 Feb 2009 01:47:00 -0000 In-Reply-To: <20090224231429.GC23254@host0.dyn.jankratochvil.net> (Jan Kratochvil's message of "Wed\, 25 Feb 2009 00\:14\:29 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2009-q1/txt/msg00236.txt.bz2 >>>>> "Jan" == Jan Kratochvil 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