On 09/20/12 13:11, Stefan Teleman wrote:
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 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 know.
Thanks,
Liviu
