On Thu, Sep 20, 2012 at 8:07 AM, Liviu Nicoara <nikko...@hates.ms> 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'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.

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.

> 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

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.

The patch is in scope for the issue at hand. The issue is that
std::numpunct and std::moneypunct are not thread safe. This has been
confirmed by 4 different thread analyzers, even after applying your
_numpunct.h patch.

You are more than welcome to submit your own patch which eliminates
100% of the race conditions.


Stefan Teleman
KDE e.V.

Reply via email to