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 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.tele...@gmail.com
