From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16488 invoked by alias); 23 Jun 2010 19:43:15 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 16468 invoked by uid 22791); 23 Jun 2010 19:43:11 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org From: Tom Tromey To: Project Archer Subject: gdb index performance Reply-To: Tom Tromey Date: Wed, 23 Jun 2010 19:43:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2010-q2/txt/msg00055.txt.bz2 Jan asked for a bit more data on the performance benefit of the gdb index work. I ran tests on 2 machines (PPC and x86 -- I still need to try x86-64). First, I installed a program plus all its debuginfo; I chose abiword for the PPC box because the I have access to didn't have enough free space for all the OO.o debuginfo, for x86 I used OO.o writer. Then I ran a script to generate all the .index files in /usr/lib/debug. Then I ran 3 "attach" tests, 5 times each. For the first set of tests I cleared the file caches before each one; for the second set I cleared the caches but then put gdb itself into the cache, to try to isolate its startup time; the third set I ran with a warm cache. I also did the same tests, but including "thread apply all bt full". This helps negate the effect of the aranges-reading code, by forcing some psymtabs to be read. I did this for a recent-ish gdb master, the system gdb (in each case a Fedora gdb, so it has the aranges code but nothing else), and then the branch that uses the indices. The results are appended. All times are in seconds, elapsed time only, average of all 5 runs. I think the results are ok, though not quite as super as I had wanted. The warm cache "bt" results are particularly good (actually I thought something went wrong so I did this again by hand -- it really is that fast) for the index approach, but I don't know how representative those are of any real-life scenario. We could probably make the cold-cache case a bit better by moving the index file mapping into the background. Also these numbers suggest that there are some other performance problems we could attack; profiling shows that minimal symbols and also name canonicalization (of minsyms) are expensive. I can email my scripts to anybody who is interested. Tom PPC attach results: +----------+----------+----------+----------+ | gdb| cold| cache gdb| warm| +----------+----------+----------+----------+ | system| 15.57| 14.02| 2.99| +----------+----------+----------+----------+ | master| 21.00| 19.35| 10.50| +----------+----------+----------+----------+ | branch| 11.02| 9.89| 1.87| +----------+----------+----------+----------+ x86 attach results: +----------+----------+----------+----------+ | gdb| cold| cache gdb| warm| +----------+----------+----------+----------+ | system| 47.76| 44.31| 2.93| +----------+----------+----------+----------+ | master| 73.07| 66.91| 13.10| +----------+----------+----------+----------+ | branch| 40.20| 36.29| 2.51| +----------+----------+----------+----------+ PPC bt results: +----------+----------+----------+----------+ | gdb| cold| cache gdb| warm| +----------+----------+----------+----------+ | system| 22.64| 20.92| 6.98| +----------+----------+----------+----------+ | master| 22.12| 20.31| 11.08| +----------+----------+----------+----------+ | branch| 12.50| 11.56| 2.11| +----------+----------+----------+----------+ x86 bt results: +----------+----------+----------+----------+ | gdb| cold| cache gdb| warm| +----------+----------+----------+----------+ | system| 110.02| 123.06| 17.53| +----------+----------+----------+----------+ | master| 78.75| 71.47| 14.85| +----------+----------+----------+----------+ | branch| 51.84| 47.07| 3.07| +----------+----------+----------+----------+