Re: stabs vs. dwarf-2 for C programs

[Daniel Berlin <dan at cgsoftware dot com>]

Daniel Berlin <dan@cgsoftware.com> writes:


> > 
> > No.  The approach saves the cost of reading the debug information from
> > the files, it saves the cost of processing the debug information for
> > duplicate information, it saves the cost of processing debug
> > information relocations, and, as you say, it saves the cost of writing
> > the debug information.
> 
> This has to be much lower than the cost of reading and writing other
> sections. There is nothing much to process. I would imagine
> that debug info sections probably take the least amount of time to
> process of all the sections, and that section time processing is
> dominated by a few section types that require more than just "read
> huge chunk->process huge chunk->write huge chunk whenever we flush for
> some reason".  I could be completely off the mark, of course.
> 
Of course, the above is someone incoherent now that i look at it
again.

I mean that it *should* be lower than the cost of reading and writing
other sections, because it should be mostly sequential i/o, with no
seeks.

The testing I did shows this currently isn't the case, which is
probably why we have link time increasing at the same rate as file
size.

In other words, I think a large increase in the debug info causing a
large increase in link time is a symptom of the disk i/o being a problem, and not the
cause of the problem itself.

If we can make it so large increases in debug info doesn't equal large
increase in linking time, i don't see a need to leave debug info in
the object files in most cases.  If it doesn't, and we can do it
without making the debugger unusable (i'm happy to implement
optimizations in the debugger to do this, if necessary), i'm all for
it.
As I said, more comprehensive testing tomorrow.

-- 
The other day, I was walking my dog around my building...  on
the ledge.  Some people are afraid of heights.  Not me, I'm
afraid of widths.