incubator-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:41:10 GMT
On 10/4/12 10:10 PM, Liviu Nicoara wrote:
> 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.

Attached some incomplete files previously. Corrected.


View raw message