[Lldb-commits] [lldb] r106045 - /lldb/trunk/include/lldb/Core/dwarf.h

Jason Molenda jason at molenda.com
Wed Jun 16 12:29:32 PDT 2010


On Jun 16, 2010, at 9:23 AM, Greg Clayton wrote:

> To answer Jason's "I have yet to see where an extra 3 characters..." comment: when you dump a very large DWARF file they tend to matter. Dumping WebCore and having an extra "DW_" in front of everything increases the size of the output by quite a bit...

I assume you're talking about dwarfdump here.  It's true, dumping the dwarf for WebKit (a very large web browser library) is a lot of output - I started dwarfdump running on the x86_64 side of the WebKit dSYM and it hasn't finished yet.  I've got 740MB of text output so far and adding "DW_" to the start of the names ("DW_AT_type" instead of "AT_type") would add about 30MB or around 4%.

I would argue that this "DW_" eliding is premature optimization.  dwarfdump has been dumping the WebKit dSYM for about an hour on my workstation with local file access for input/output and it hasn't completed yet.  I redirected the output of dwarfdump to a file (instead of using the -o option) which may be to blame but the process is using around 2-3% of the CPU.  Outputting 700MB of formatted text should not take nearly this much time -- either dwarfdump is reading data off the disk inefficiently or outputting it inefficiently.

The drawback to not outputting "DW_" is for end users.  For us, we can look at "AT_type" and say, Oh yes of course that means DW_AT_type.  But for someone less familiar with DWARF who is trying to understand the format or diagnose a problem related to debug info, it's an additional hurdle they have to compensate for if they are googling for the definitions or looking through the DWARF standards document.

I'd argue that eliding "DW_" does not solve the performance problems and reduces understandability for out users.  It's a poor tradeoff.

J



More information about the lldb-commits mailing list