Re DW_FORM_string the savings is small but since it came up I thought I'd mention the idea. I agree it's not worth pursuing any further. An API to use that form explicitly (that isn't the normal debug-info generation API) to facilitate testing is fine. Regarding DWARF parsing speed where strings are concerned: DWARF 5 will ruin this because DW_FORM_strx is a ULEB; so, every DIE that has a DW_AT_name or DW_AT_linkage_name will become variable-size (just as bad as DW_FORM_string). In a RelWithDebInfo build of Clang, I got just over 100 million DIEs and 40.2% had DW_AT_name. I didn't try to count DIEs that had DW_AT_linkage_name without DW_AT_name; it can happen, though, so the number of variable-size DIEs in DWARF 5 will actually be higher than that. Maybe we should propose a fixed-size variant of FORM_strx, or that strx just be fixed size? The public-comment review period for DWARF 5 is not over yet, and this seems like a valid concern. --paulr
> Regarding DWARF parsing speed where strings are concerned: DWARF 5 will > ruin this because DW_FORM_strx is a ULEB; so, every DIE that has a > DW_AT_name or DW_AT_linkage_name will become variable-size (just as bad > as DW_FORM_string). In a RelWithDebInfo build of Clang, I got just over > 100 million DIEs and 40.2% had DW_AT_name. I didn't try to count DIEs > that had DW_AT_linkage_name without DW_AT_name; it can happen, though, so > the number of variable-size DIEs in DWARF 5 will actually be higher than > that.More data from my RelWithDebInfo build of Clang: 102,654,608 total DIEs 95,864,960 fixed-size in DWARF 4 58,189,225 fixed-size in DWARF 5, assuming all FORM_strp attributes become FORM_strx That is, fixed-size DIEs go from 93% to 57% of all DIEs. If it's really faster to load fixed-size DIEs, this is likely to have a noticeable effect.> > Maybe we should propose a fixed-size variant of FORM_strx, or that strx > just be fixed size? The public-comment review period for DWARF 5 is not > over yet, and this seems like a valid concern.I have a little more data to look at but I am going to propose this to the DWARF committee.> --paulr > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
On Fri, Nov 18, 2016 at 5:51 PM Robinson, Paul <paul.robinson at sony.com> wrote:> > Regarding DWARF parsing speed where strings are concerned: DWARF 5 will > > ruin this because DW_FORM_strx is a ULEB; so, every DIE that has a > > DW_AT_name or DW_AT_linkage_name will become variable-size (just as bad > > as DW_FORM_string). In a RelWithDebInfo build of Clang, I got just over > > 100 million DIEs and 40.2% had DW_AT_name. I didn't try to count DIEs > > that had DW_AT_linkage_name without DW_AT_name; it can happen, though, so > > the number of variable-size DIEs in DWARF 5 will actually be higher than > > that. > > More data from my RelWithDebInfo build of Clang: > > 102,654,608 total DIEs > 95,864,960 fixed-size in DWARF 4 > 58,189,225 fixed-size in DWARF 5, assuming > all FORM_strp attributes become FORM_strx > > That is, fixed-size DIEs go from 93% to 57% of all DIEs. > If it's really faster to load fixed-size DIEs, this is likely to have > a noticeable effect. > > > > > Maybe we should propose a fixed-size variant of FORM_strx, or that strx > > just be fixed size? The public-comment review period for DWARF 5 is not > > over yet, and this seems like a valid concern. > > I have a little more data to look at but I am going to propose this to > the DWARF committee. > >Agreed. Let's talk offline about a proposal here if you'd like. -eric> > --paulr > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161119/c9528754/attachment.html>