This is the mail archive of the
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: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
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
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.
> 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.