This is the mail archive of the
mailing list for the libstdc++ project.
Re: merge branch profile-stdlib
Silvius, I wanted to give you some quick feedback on your branch this
week. I haven't been following this branch super closely but have
checked it out, and started to read your documentation and build/play
with it. However, I will be gone until mid-week and unable to follow-up
So, take these as preliminary notes. Sorry if they are rushed or
There are some interesting ideas here. I would like some more time to
look at the way this is organized, and think about the way options
are presented to users. But in general, I think that there is merit in
> I would like to merge the profile-stdlib branch into trunk. I made
> the changes requested by your previous reviews:
> - Gave up on adding a runtime library. The diagnostic implementation
> was moved from profc++/ to include/profile/impl/.
> - Reverted driver changes so that the interface is -D_GLIBCXX_DEBUG,
> consistent with current extensions.
I think you mean _GLIBCXX_PROFILE here.
> Before I go with a fine comb, could you please take a look at the
> branch and let me know if there are any other major issues?
In profile_mode.xml, need to revisit for -fprofile-stdlib status. Also,
can replace "stdlib" and "stdlibc++" with libstdc++.
> The big picture organization is:
> - All profile extension headers live in include/profile/. They
> include profile/base.h.
> - All diagnostic implementations live in include/profile/impl/. They
> are included by profile/impl/profiler.h.
> - profile/base.h includes profile/impl/profiler.h. This is the only
> direct connection between include/profile/ and include/profile/impl/.
> - The relation with debug and parallel extensions has not been
I'm currently of the mind that all these extensions should be mutually
> - We are using vector and unordered_map in the implementation, with
> default allocators. This can cause infinite cycles if say the
> application code uses libstdc++ containers to gather allocation
As with Jonathan, this strikes me as something to be fixed sooner
rather than later. As you say, the design flaw is understood (custom
allocators for internal vector and unordered_map instances.)
> - The machine-specific performance model component is not on the
> branch. I decided to treat it as a separate component and add it
> later. The decisions are based on generic operation performance
Can we get some visibility here in terms of a specific instance of a
machine-specific model? This seems very hand-wavy. Where are you going
Certainly, Cost Model: Math goes here
is not sufficient.
> - Many diagnostics have not been implemented yet.
Is there a list of possible directions for future work? I see a lot
already. I'm interested in where you are going with
Stepping back a bit, now that you have this, can you show how it's
applied to some kind of C++ source base? How would this be integrated
into a user's build system? How are you using it in the real world? Has
it been useful? What kind of expectations should we have about execution
speed w/ profile-stdlib active, given that you had concerns about debug