This is the mail archive of the
mailing list for the libstdc++ project.
Re: debug extension overhead
On Wed, Jun 3, 2009 at 1:13 AM, Jonathan Wakely <firstname.lastname@example.org> wrote:
> 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() ? :-)
I think std::vector::at() will run the check in non-debug builds as
well, whereas something conditioned by -DDEBUG will be turned off for
> > 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.
That could work for us. Users are generally reluctant to build two
sets of debug object files, one for unittests and another for whole
app testing, but automated regression checkers could build and run
unittests with -D_GLIBCXX_DEBUG.