Hi Silvius Rus and Lixia Liu! Thanks for posting this, asking for advice, and being willing to help improve libstdc++!
> Goal: Give performance improvement advice based on analysis of > dynamic STL usage. Your project sounds intriguing, and something that could potentially be useful for GNU C++ users. I look forward to seeing how your work progresses, and encourage you to start a gcc branch to house your work in progress. Progress can be evaluated at the next stage 1 window, to see if things are solid enough to merge in to the trunk. > Method: Instrumentation calls in libstdc++-v3/include/debug/*, > runtime support library in libstdc++-v3/libstladvisor, trace > analysis/report tool in libstdc++-v3/stladvisor. I would like to see a bit more detail on your methodology, and encourage you to immediately start working on user documentation and a test strategy before you get too far along with anything else. For documentation, you'll need something similar to: http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html 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? It seems to me like you might want to provide a third level of debug mode macro, in addition to the _GLIBCXX_DEBUG and _GLIBCXX_DEBUG_PEDANTIC, maybe something like _GLIBCXX_DEBUG_PROFILE. However, if this is not the way you wish to proceed, and the intention is to be separate from debug mode, I would suggest using a new directory hierarchy and naming convention, one that is more descriptive to what you are attempting than "advisor". Perhaps include/profile? _GLIBCXX_PROFILE? Etc etc. In any case, please explain a bit more as to how this relates to debug mode. How do you intend to test this functionality? Do you intend for this functionality to work on all, some, or most platforms? What are the portability concerns or issues? > There are other STL usage patterns that can be recognized and > reported to the application programmer. Again, scope. It would be great to provide an initial list so we know what is being attempted. Feel free to mark some of them as stretch goals, or things that will not be attempted immediately. > The effect of our instrumentation is a meaningful trace of the > behavior of containers, algorithms and iterators, and their > interaction. This abstraction level is above what normal profiling > tools can offer. If we used normal profiling tools, we would have to > reverse engineer the trace to get to this level of abstraction. Let > me know if you want me to go into more detail. More detail, please. > Design > ====== > > The usage model is intended to be similar to -fprofile-generate and > -fprofile-use. > > 1. Compiler driver > Build with instrumentation: gcc -fstl-advisor=instrument:all foo.cc. > The effect on the compiler is simply "|-D_GLIBCXX_DEBUG > |-D_GLIBCXX_ADVISOR". The effect on the linker is "-lstladvisor". Seems fine. > Run program: ./a.out. OK. > Produce advisory report: gcc -fstl-advisor=use:advise. What other valid input do you anticipate -fstl-advisor having? best, benjamin