debug extension overhead

[Silvius Rus]

On Wed, May 20, 2009 at 11:35 AM, Benjamin Kosnik <bkoz@redhat.com> wrote:
>
> > Have you considered adding a knob that would turn on a subset of
> > _GLIBCXX_DEBUG checks that have lower overhead, e.g., guaranteed
> > constant factor?  Some users are giving up on it due to high overhead
> > in certain cases, but they could benefit from cheap checks, such as
> > vector subscript checks.
>
> Hmm. The idea was that for fine-grained checks, one would just select
> the debug extension on a per-header basis, instead of using
> _GLIBCXX_DEBUG. Ie, including debug/vector and
> using __gnu_debug::vector if all you want is vector subscript checks.
>
> Can you provide more detail for the scenario you mention above, users
> giving up on it due to high overhead? Examples with specifics
> (code, gcc release, target) please.
>

Sorry, I missed your answer earlier.  I dug up the information and the
scenario goes like this:
There are a few large applications for which _GLIBCXX_DEBUG does not
work due to some problems with hash_map.  I had assumed it was a
performance issue, but it turns out to be functional.  I don't know
whether that's been fixed on trunk.  We should try to fix it, but
we're pulling in third party code often, so this is likely to happen
again.  Regardless whether the reason is performance or functionality,
it would be useful to have knobs to turn off say hash_map diagnostics,
or expensive checks.

I was not aware of the use model where you include debug/vector and
use __gnu_debug::vector.  That should do for avoiding functional
issues, but is awkward to use with a very large code base.

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.
(That's tempting and it happened already.)  Since this would apply to
-O0 builds, a somewhat uniform constant factor performance decrease is
tolerable.  However, I would like to be able to turn off all checks
that take more than constant time.

Is there a list of asymptotic overhead bounds for the checks done with
_GLIBCXX_DEBUG?

> > Also, it would increase its usability in time sensitive applications.
>
> 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.

Thank you,
Silvius