From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1580 invoked by alias); 6 Dec 2009 03:41:24 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 1571 invoked by uid 22791); 6 Dec 2009 03:41:23 -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: Paul Pluzhnikov Cc: Daniel Jacobowitz , Cary Coutant , Dodji Seketeli , "GDB\/Archer list" Subject: Re: [RFC] Proposal for a new DWARF name index section References: <4A7FE28D.4050901@redhat.com> <4A8D8868.3010302@redhat.com> <20091202051717.GA24978@caradoc.them.org> <20091202173518.GA13838@caradoc.them.org> <20091202193852.GA23631@caradoc.them.org> <8ac60eac0912021746g3cc9b543j1b175cf80b433705@mail.gmail.com> Reply-To: Tom Tromey Date: Sun, 06 Dec 2009 03:41:00 -0000 In-Reply-To: (Tom Tromey's message of "Fri, 04 Dec 2009 16:12:57 -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/msg00083.txt.bz2 >>>>> "Tom" == Tom Tromey writes: Tom> If we can get acceptable performance without a cache, then I think that Tom> would be preferable. One trouble with caching is that it is still slow Tom> the first time. Tom> So far, it is clear that we can improve performance. It is less clear Tom> whether we can improve it enough, but I'm working on finding out. It turns out that we can make it start very fast by assuming that if we see .debug_gnu_index, then we are going to use both it and .debug_aranges. I changed the code to make this assumption, and to lazily map all debug sections. With this in the place the results are ridiculously great, like: 0.15user 0.02system 0:00.21elapsed I also found out that testing this code with "gdb -batch" introduces a bit of confusion into the results, because that will call find_main_filename, which will require some symbol table information. I've taken to disabling this code when looking at timings. Also, I made another funny hack tonight. I changed gdb to read .debug_aranges and .debug_gnu_index in a background thread. This was pretty easy to do; it really just few a couple global __thread variables. (I didn't attempt reading full symbols in a separate thread, because that seems a lot more involved.) What this means is that the user will still see very fast startup times, but also will typically have less waiting when he runs a command. The problem with this "fast" patch is that we are really just deferring some work until it is needed. But, when it is needed we still have to spend the time to actually read the index. Threading lets us hide a bit of that work. I would guess that threading will be met with revulsion :-). But, it seems very practical in this case. I'll clean up this patch a bit and push it to a new branch in archer this week. Tom