Re: doZeroOnPush

On 26/01/2013 6:56 a.m., Alex Rousskov wrote:
> On 01/24/2013 07:27 PM, Amos Jeffries wrote:
>> On 24/01/2013 11:36 p.m., Kinkie wrote:
>>> On Thu, Jan 24, 2013 at 11:28 AM, Amos Jeffries wrote:
>>>> On 24/01/2013 5:56 a.m., Kinkie wrote:
>>>>> Hi Amos,
>>>>> what is the best way to signal in a mempools client that the
>>>>> constructor is complete and that thus zeroing is not necessary? It's
>>>>> not immediately evident from looking at the source..
>>>>> It seems that this is only done in mem.cc for string pools.
>>>> memDataInit() has an optional bool flag. Set it to false.
>>> .. I still can't fully understand how it relates to the usual
>>> MEMPROXY_CLASS/MEMPROXY_CLASS_INLINE, and I can't find any good
>>> example.
>>>
>>>
>>> --
>>> /kinkie
>> I think I found the answer. And its no good...
>>
>> The objects defined with MEMPROXY_CLASS() macro are all using
>> MemAllocatorProxy::getAllocator() in lib/MemPools.cc to late-initialize
>> their pools. There is no zero flag being passed around in any of those
>> macros or their code paths.
>>
>> So far as I can see to make it optional we will need to make either a
>> template or a new macro which accepts the flag and saves it for use when
>> MemAllocatorProxy::getAllocator().create(...) is done. The doZero()
>> setter needs to be called from the same if() condition right after
>> MemAllocatorProxy::getAllocator().create().
>>
>> So:
>> 1)
>> - update the macro and roll it out in one step defaulting as (true)
>> everywhere
>> - then set it to false as things get verified.
>> - then eventually remove it again when we have a fully no-zero state
>> for all classes.
> I think this is the best option, especially if you trust Coverity to
> eventually find all initialization problems. It comes with virtually no
> initial risk and results in very few code changes.
>
>
>> 2)
>> - add a second macro which sets it to true.
>> - roll out a conversion to the new maro
> OK, but I think #1 is better because #1 results in fewer code changes. I
> may change my opinion if Kinkie's tests prove that fewer doZero buffers
> result in significantly better performance, justifying per-class,
> incremental changes.
>
>
>> 3)
>> - make a template which can replace MEMPROXY_CLASS() etc. with zero
>> optional flag
>> - rollout the template as we verify classes are constructed properly
> Doable, but too complex IMO, without much added benefit that I can see.

Complex?

Do you have any examples I can take a look at? Just for my edification.
I will take your word for it not being worthwhile persuing for now.

Amos
Received on Sat Jan 26 2013 - 04:49:21 MST