From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22808 invoked by alias); 11 Dec 2009 23:10:01 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 22757 invoked by uid 22791); 11 Dec 2009 23:09:59 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org From: Tom Tromey To: Project Archer Subject: Re: Initial psymtab replacement results References: Reply-To: Tom Tromey Date: Fri, 11 Dec 2009 23:10:00 -0000 In-Reply-To: (Tom Tromey's message of "Thu, 10 Dec 2009 14:54:09 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2009-q4/txt/msg00091.txt.bz2 >>>>> "Tom" == Tom Tromey writes: Tom> * Test out using pubnames + pubtypes instead of the new section. Tom> I remain skeptical about this but it seems important to be sure. I thought of a way to approximate the performance of this without actually implementing it. According to my theory, the most important thing is to avoid reading .debug_info (et al) during startup. And, we already know that using .debug_pub* will require reading the CU DIE. So, I simply modified gdb to always read the CU DIE. GDB Cold Cache Warm Cache ======================================= baseline 1:24 0:56 branch 0:45 0:19 DIE 0:54 0:21 So... it is worth about a 15% speedup in the cold cache case. Still, it is hard to know whether this is justified in terms of the overall effort. OO.o is a pretty big program, and 10 seconds doesn't exactly give the user that "wow" factor. I'm leaning toward ditching the .debug_gnu_index idea and simply going with the standard sections instead. Let me know what you think of this. As far as I know the .debug_pub* approach is ok assuming (1) we take Cary's suggestion of changing gcc to put everything in it, and (2) parse the producer to see when the sections are usable. Jan mentioned on irc yesterday that we could probably do better by avoiding reading any debuginfo at all during startup. For the "attach" case we could additionally use info from the inferior to determine which objfile the PC is in -- so we would not have to read anything from most objfiles. (Perhaps in conjunction with lazily reading minimal symbols.) The possible issue with this is latency. This is what bit us with the delayed-symfile branch: we could hide the initial work easily, but it was (very) noticeable later, because gdb would pause for a long time in response to some user command. To look at this, I instrumented gdb to print the amount of time taken to read the index for each objfile. There were 170 objfiles with debuginfo in OO.o, with a median reading time of 7999 microseconds, a mean of 30277 microseconds, and a maximum of 641903 microseconds. This indicates to me that the latency problem would not be severe for the PC-lookup case. However, I think it would be just as bad as delayed-symfile for the name-lookup case, because name-lookup doesn't let us pick the needed objfile a priori. Perhaps this is an area where the threaded branch can help. Tom