This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: New branch for STL Advisor
- From: "Doug Gregor" <doug dot gregor at gmail dot com>
- To: "Benjamin Kosnik" <bkoz at redhat dot com>
- Cc: "Silvius Rus" <rus at google dot com>, gcc at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, paolo dot carlini at oracle dot com, "David Li" <davidxl at google dot com>, "Lixia Liu" <lixialiu at google dot com>
- Date: Mon, 14 Jul 2008 21:22:55 -0400
- Subject: Re: New branch for STL Advisor
- References: <4877D666.7070206@google.com> <20080714162021.5c1954cf@balbo.artheist.org>
On Mon, Jul 14, 2008 at 7:20 PM, Benjamin Kosnik <bkoz@redhat.com> wrote:
> In particular, design. The using bits seem pretty straightforward. It
> would be nice if you could provide some detail in terms of scope (what
> are the algorithms or data structures you intend to instrument),
> and how this fits into the existing debug mode functionality. Do you
> need the debug mode functionality, or are just piggy-backing off this
> existing structure?
This ties in with the main question I had... typically, a profiling
layer is used on larger inputs where it is important that the
profiling code itself have very low overhead. Piggybacking on the
debug mode is a definite performance-killer, so I hope that the
profiling version of the library will be in its own inline namespace
alongside the parallel and debug modes.
My vote for the command-line switch is -fprofile-stdlib.
- Doug