incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Teleman <stefan.tele...@gmail.com>
Subject Re: STDCXX-1056 : numpunct fix
Date Thu, 20 Sep 2012 17:11:05 GMT
On Thu, Sep 20, 2012 at 8:07 AM, Liviu Nicoara <nikkoara@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
Knuth.

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

-- 
Stefan Teleman
KDE e.V.
stefan.teleman@gmail.com

Mime
View raw message