From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29121 invoked by alias); 26 Feb 2004 23:12:58 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 29079 invoked from network); 26 Feb 2004 23:12:56 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 26 Feb 2004 23:12:56 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AwUgZ-0002jI-UJ; Thu, 26 Feb 2004 18:12:55 -0500 Date: Thu, 26 Feb 2004 23:12:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com, Elena Zannoni Subject: Re: [RFA/dwarf] Optimize partial DIE reading for uninteresting DIEs Message-ID: <20040226231255.GC8487@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com, Elena Zannoni References: <20040225030644.GA5167@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00788.txt.bz2 On Thu, Feb 26, 2004 at 05:28:18PM -0500, Jim Blandy wrote: > Daniel Jacobowitz writes: > > > read_partial_die is a pretty heavyweight function. One of the largest > > indicators of this is how high read_uleb128 shows up in startup profiles. > > This patch provides an alternative for DIEs we know are uninteresting: we > > can just read in the abbrev, and the sibling pointer if any. > > > > Performancewise, on mainline this is a bit of a wash for typical code. > > That's because we read every file-scope or namespace-scope DIE using > > read_partial_die before we decide if it's interesting. A followup patch to > > use peek_die_abbrev for that provides a several percent improvement in GDB > > startup time. > > Hmm. If I'm reading this right, the only real difference between > calling skip_children and calling locate_pdi_sibling is that the > former calls skip_one_die to get past the attributes, while the latter > calls read_partial_die. Is that right? > > skip_one_die: > - stops skipping attributes as soon as it sees a sibling pointer, > - doesn't read the attributes' values, and > - doesn't examine the attributes to fill in a partial_die_info > structure. > > But none of that really sounds too expensive, so I'm not surprised > that this change alone is a wash, and I'm curious to see the followup > patch. You haven't posted that yet, right? Only the version for the intercu branch. The reason this is a wash is, as I said above, only because this function is not called as often as it could be. The followup is to use it in place of read_partial_die in a more common case - when the DIE is something we won't build partial symbols for. For instance, types that we know will not have names. We can read just the abbrev and then skip everything else. I could do considerably better than the current implementation, too, though I'm not sure it's worthwhile. You're mistaken about the expense. In particular read_unsigned_leb128 is much slower than skip_uleb128 because of the computations to build the result; IIRC variable shifts are expensive. Yes, this was measured with an optimized build and a non-intrusive profiler. There's also the different memory access patterns. > It bothers me that the patch would give us two separate form parsers. > It would be nicer if we could just have one function that knows how to > get the proper value of each attribute. Would it be possible for > skip_one_die to call read_attribute, instead of writing out its own > switch? Yes, that would allocate space for the blocks on > dwarf2_tmp_obstack, but I think there are comments in > dwarf2_build_psymtabs_hard explaining that this isn't significant. > For most everything, read_attribute_value just hands out pointers into > the info or string buffer. And you're still not going to be reading > past any sibling attributes, so in the common case you'll never read > much anyway. Most of the speedup comes from not reading in the attribute values, though. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer