This is the mail archive of the
mailing list for the GCC project.
Re: libstdc++-v3 PATCH: STL configuration change
- To: rittle at labs dot mot dot com
- Subject: Re: libstdc++-v3 PATCH: STL configuration change
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Wed, 30 May 2001 11:46:09 -0700 (PDT)
- cc: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
Loren, thanks for your excellent and very detailed work. I would appreciate
it if you'd add links to your last message and initial performance
analysis in the faq/howtos.
Please check this patch in, to both trunk and branch.
I'd love it if some kind of regression went it to test this stuff, but
I'm not quite sure how to do this.
We really need to think of a new catagory of testsuite cases, that test
for memory leaks (the string memory issue comes immediately to mind as
another test case in this category).
It would also be nice to have some kind of automated
way where performance analysis could be done as part of running the
testsuite. The old mkcheck script did this a bit, by measuring runtime
speed. I suppose if we looped critical blocks we could even measure
performance differences. (Of course there's an endless hole here of
cache, avoiding cache, etc.)
Still, I'd like people to try and set up a framework for tests of this
kind. I think it's really important, especially as more people work on tuning
libstdc++-v3, that some kind of non-hand-wavy, explicit and quantative
method is in place for measuring performance claims. A place to start
might be some of the bench++ work, and seeing if those measurement
techniques can be brought over to the libstdc++-v3 testsuite.