Re: call for libstdc++ profile mode diagnostic ideas

[Silvius Rus <rus at google dot com>]

On Wed, Feb 16, 2011 at 12:51 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
>
> On Thu, 16 Dec 2010, Silvius Rus wrote:
>
>> - container selection (e.g., replace list with deque).
>
> I just wanted to mention that I've had a case today where this exact advice would have been welcome. The list was used with only empty() and
> (push_|pop_|)(front|back), and although deque is not optimal, it still performs better than list in this case.
>

Thank you for the report!  We got this suggestion first from Ian
Taylor, who saw similar behavior on the gold linker.  In his case
there were no front operations, so perflint suggested replacing list
with vector, but deque is probably the better answer there as well.

>
> It is not always very convenient that all programs use the same file name for their output, but we worked around that.
>

You can set it as an environment variable value:
_GLIBCXX_PROFILE_TRACE_PATH_ROOT=/tmp/program1 ./a.out
There were also suggestions about appending the process id to the file
name but that didn't get implemented.

> Do you have a convenient script to turn the call stack into something human-readable? Using backtrace_symbols for the .txt file would be nice.

I used to have a post-procesing python script based on addr2line but
that got out of sync with changes in format.  I'll fix/write a new one
and get back.  I don't know exactly how backtrace_symbols works (where
it keeps the names) so I can't tell whether it would be worth trying
to switch to it.  However, the post-processing tool will likely be
needed anyway, at least for cases where a binary runs in production
environment where it gets stripped of symbols.  Then you'd get the
addresses at run time and do symbolization offline.

> Thank you for the profile mode,

Sure!  I hope to have several more diagnostics and usability
improvement in the gcc 4.7 time frame.  In particular I'm interested
to reduce the runtime overhead through sampling.

Silvius