stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Nicoara <>
Subject Re: Fwd: Re: STDCXX-1071 numpunct facet defect
Date Fri, 05 Oct 2012 02:10:35 GMT

On 10/3/12 11:10 AM, Martin Sebor wrote:
> On 10/03/2012 07:01 AM, Liviu Nicoara wrote:
>> I am gathering some more measurements along these lines but it's time
>> consuming. I estimate I will have some ready for review later today or
>> tomorrow. In the meantime could you please post your kernel, glibc and
>> compiler versions?
> I was just thinking of a few simple loops along the lines of:
>    void* thread_func (void*) {
>        for (int i = 0; i < N; ++)
>            test 1: do some simple stuff inline
>            test 2: call a virtual function to do the same stuff
>            test 3: lock and unlock a mutex and do the same stuff
>    }
> Test 1 should be the fastest and test 3 the slowest. This should
> hold regardless of what "simple stuff" is (eventually, even when
> it's getting numpunct::grouping() data).

That is expected; I attached test case x.cpp and results-x.txt.

I did not find it too interesting in its own, though. The difference between the 
cached and non-cached data is that in the case of the cached data the copying of 
the string involves nothing more than a bump in the reference counter, whereas 
in the non-cached version a string object is constructed anew, and memory gets 
allocated for its body. Yet, in my measurements, the cached version is the one 
which shows the worse performance.

So, I extracted the std::string class and simplified it down and put it in 
another test case. That would be u.cpp and the results are results-u.txt. The 
results show the same performance trends although the absolute values have 
skewed. Will get back to this after I digest the results a bit more.


View raw message