incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Nicoara <>
Subject Re: STDCXX-1056 : numpunct fix
Date Thu, 20 Sep 2012 21:07:22 GMT
On 09/20/12 13:11, Stefan Teleman wrote:
> On Thu, Sep 20, 2012 at 8:07 AM, Liviu Nicoara <> wrote:
>> But have you measured the amount of memory consumed by all STDCXX locale data loaded
in one process? How much absolute time is spent in resizing the locale and facet buffers?
What is the gain in space and time performance with such a change versus without? Just how
fragmented the heap becomes and is there a performance impact because of it, etc.? IOW, before
changing the status quo one must show an objective defect, produce a body of evidence, including
a failing test case for the argument.
> sizeof(std::locale) * number_of_locales.

I was more interested in the underlying locale data, not the C++ objects.

> I'll let you in on a little secret: once you call setlocale(3C) and
> localeconv(3C), the Standard C Library doesn't release its own locale
> handles until process termination. So you might think you save a lot
> of memory by destroying and constructing the same locales. You're
> really not. It's the Standard C Library locale data which takes up a
> lot of space.

Thanks for the secret, I appreciate it. Did you mean to say that the C Standard mandates that?!

> What I do know for a fact that this "optimization" did, was to cause
> the races conditions reported by 4 different thread analyzers. Race
> conditions are a show-stopper for me, and they are not negotiable.

No, that optimization was not causing the MT defect you originally noted. Saying so only shows
a lack of familiarity with the implementation.

>> And I love minimalistic code, and hate waste at the same time, especially in a general
purpose library. To each its own.
> Here's a helpful quote:
> "We should forget about small efficiencies, say about 97% of the time:
> premature optimization is the root of all evil". It's from Donald
> Knuth.

Please, no.

> And I love correct code which doesn't cause thread analyzers to report
> more than 12000 race conditions for just one test case. I've said it
> before and I will say it again: race conditions are a showstopper and
> are not negotiable. Period.

Stefan, you are not being correct by a consensus of thread analyzers output or by being loud,
or by pounding your fist on the table. This being said I will continue to exercise due diligence
and put in the necessary time and effort to provide you with the most useful feed-back I can.

I see that you missed my question in the post before: did you see a failure in the locale
MT tests in your SPARC runs? If you do not want to run that test, that is fine, just let me


View raw message