Benjamin Kosnik wrote:
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 pot
Doug Gregor wrote:
On Mon, Jul 14, 2008 at 7:20 PM, Benjamin Kosnik <[EMAIL PROTECTED]> 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 ins
> 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 libr
On Mon, Jul 14, 2008 at 7:20 PM, Benjamin Kosnik <[EMAIL PROTECTED]> 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 t
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++
Paolo Carlini wrote:
... finally (for now ;), an apparently pedantic issue, but really I'm going to strongly
object to any use of "STL" together with our implementation of the ISO C++
Runtime Library: it's a *legacy* HP / SGI acronym which is not used anywhere in the ISO
Standard in force (C++
Paolo Carlini wrote:
Also, maybe it's just me, but the specific advantages over normal profiling /
existing tools, don't seem completely obvious, I'd like to see that point
discussed in better detail...
Paolo.
The effect of our instrumentation is a meaningful trace of the behavior
of co
Paolo Carlini wrote:
libstdc++-v3 maintainers, could you please comment/advise?
Can you explain which is the role of the debug-mode code, here? Because certainly the
*performance* of the debug-mode library have *nothing* to do with the performance of the
"real" library (whether that coul
The advisory tool aims to give high-level suggestions, mostly focuses on
the access pattern and size of STL.
Such as, shown in example, we want to decide the right initial size for
the container to reduce execution time as much as possible.
Another case is we can suggest that a hash-map is more
... finally (for now ;), an apparently pedantic issue, but really I'm going to
strongly object to any use of "STL" together with our implementation of the ISO
C++ Runtime Library: it's a *legacy* HP / SGI acronym which is not used
anywhere in the ISO Standard in force (C++98 + TC1) or in the wor
Also, maybe it's just me, but the specific advantages over normal profiling /
existing tools, don't seem completely obvious, I'd like to see that point
discussed in better detail...
Paolo.
> libstdc++-v3 maintainers, could you please comment/advise?
Can you explain which is the role of the debug-mode code, here? Because
certainly the *performance* of the debug-mode library have *nothing* to do with
the performance of the "real" library (whether that could be improved, tweaked,
or
12 matches
Mail list logo
