call for libstdc++ profile mode diagnostic ideas

[Silvius Rus <rus@google.com>]

Hello libstdc++ developers and users,

(I cc-ed gcc@gcc.gnu.org for a larger audience as others may offer
suggestions not as library developers but as C++ programmers.  Sorry
in advance if this is spam to you.)

I'm planning to add a set of new performance diagnostics to the
libstdc++ profile mode
(http://gcc.gnu.org/onlinedocs/libstdc++/manual/profile_mode.html) and
am trying to come up with a list of what diagnostics are most
meaningful and most wanted.

The profile mode currently gives diagnostics such as "use
unordered_map instead of map at context ...".  The full list is at
http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt03ch19s07.html.

At this (brainstorming) point I'm looking for any suggestions,
including and not limited to:
- container selection (e.g., replace list with deque).
- container implementation selection (e.g., string implementation).
- algorithm selection (e.g., sort implementation)
- data structure or algorithm parameter selection (e.g., fixed string
reserved size value for a particular context).

Please reply to this message or email me privately (rus@google.com) if
you have any suggestions for new diagnostics, or about the profile
mode in general, or to express your support for a particular proposed
diagnostic.  For new diagnostics, it works best if you can provide:
- A simple description, e.g., "replace vector with list".
- (optional) The instrumentation points, even if vague, e.g.,
"instrument insertion, element access and iterators".
- (optional) How the decision is made, e.g. "there are many inserts in
the middle, there is no random access and it's not iterated through
many times".
Keep in mind that profile mode analysis is context sensitive (context
= dynamic call stack), so it's OK to propose both "change list to
vector" and "change vector to list", with different criteria sets as
they may both be right in different contexts.

To make sure the diagnostics are realistic, keep in mind that analysis
is usually based on observing, at run time, container state before and
after each operation on the container or on iterators of the
container.

Once I have a good pool of ideas and preferences, I will present a
refined set to libstdc++@gcc.gnu.org for discussion.


Thank you,
Silvius