This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: debug extension overhead
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Silvius Rus <rus at google dot com>
- Cc: Benjamin Kosnik <bkoz at redhat dot com>, libstdc++ at gcc dot gnu dot org
- Date: Wed, 3 Jun 2009 09:13:24 +0100
- Subject: Re: debug extension overhead
- References: <e90dbffc0905201117m466d7ba6jf19c66fa882a8a56@mail.gmail.com> <20090520113552.2aa22a3d@mcgee.artheist.org> <e90dbffc0906022237r77ca2a57o60a0f9b24e3dd1e7@mail.gmail.com>
2009/6/3 Silvius Rus:
> Coming back to performance guarantees. We are considering turning on
> _GLIBCXX_DEBUG with say "-O0 -g" builds, but need to assure users that
> the overhead is acceptable. I am trying to avoid users writing their
> own vector wrapper that adds simple bounds checks with -DDEBUG.
What's wrong with std::vector::at() ? :-)
> Is there a list of asymptotic overhead bounds for the checks done with
> _GLIBCXX_DEBUG?
There are no performance guarantees for debug mode. The overhead is
whatever is necessary to achieve the checking.
>> Usability in time sensitive applications is not and has never been a
>> design goal for debug extensions.
>>
>> -benjamin
>
> That's fine. However, I would like to be able to debug an application
> that makes decisions based on the amount of time it takes to perform
> some operations. If the operation ratios change too much, the dynamic
> program paths change, so I'm not debugging the original behavior.
> Turning on just a subset of guaranteed constant overhead checks might
> just do, since the overhead will likely distribute fairly uniformly,
> so operation ratios won't change too much.
One option would be to use debug mode in unit tests for individual
components, to verify correct stdlib usage separate from
time-sensitive behaviour as part of a larger system, but not to try
and enable it routinely for entire applications.
Jonathan