Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c) - Mailing list pgsql-hackers

From mahendrakar s
Subject Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)
Date
Msg-id CABkiuWr1+FFcSFM=qW3vnj3R4VHktB57WihfXUpCzURgeLTNUA@mail.gmail.com
Whole thread Raw
In response to Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)  (Ranier Vilela <ranier.vf@gmail.com>)
Responses Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)
List pgsql-hackers
Hi Ranier,

I'm pretty late to thread but would like to know about your claim in the thread:
`All compilers currently have memset optimized.` I know one case of optimization where variable is not used after the memset.
Are the cases for which the optimization is done consistent across all the compilers? 

Thanks,
Mahendrakar.


On Tue, 2 Aug 2022 at 17:26, Ranier Vilela <ranier.vf@gmail.com> wrote:
Em seg., 1 de ago. de 2022 às 22:19, Peter Smith <smithpb2250@gmail.com> escreveu:
On Tue, Aug 2, 2022 at 3:09 AM Ranier Vilela <ranier.vf@gmail.com> wrote:
>
> Em sáb., 16 de jul. de 2022 às 16:54, Ranier Vilela <ranier.vf@gmail.com> escreveu:
>>
>>
>>
>> Em sáb, 16 de jul de 2022 2:58 AM, Peter Eisentraut <peter.eisentraut@enterprisedb.com> escreveu:
>>>
>>> On 11.07.22 21:06, Ranier Vilela wrote:
>>> > Em qui., 7 de jul. de 2022 às 14:01, Ranier Vilela <ranier.vf@gmail.com
>>> > <mailto:ranier.vf@gmail.com>> escreveu:
>>> >
>>> >     Attached the v1 of your patch.
>>> >     I think that all is safe to switch MemSet by {0}.
>>> >
>>> > Here the rebased patch v2, against latest head.
>>>
>>> I have committed my patch with Álvaro's comments addressed
>>
>> I see.
>> It's annoing that old compiler (gcc 4.7.2) don't handle this style.
>>
>>>
>>> Your patch appears to add in changes that are either arguably out of
>>> scope or would need further review (e.g., changing memset() calls,
>>> changing the scope of some variables, changing places that need to worry
>>> about padding bits).  Please submit separate patches for those, and we
>>> can continue the analysis.
>>
>> Sure.
>
> Hi, sorry for the delay.
> Like how https://github.com/postgres/postgres/commit/9fd45870c1436b477264c0c82eb195df52bc0919
> New attempt to remove more MemSet calls, that are safe.
>
> Attached v3 patch.
>
> regards,
> Ranier Vilela

Hi, I have not been closely following this thread, but it's starting
to sound very deja-vu with something I proposed 3 years ago. See [1]
"Make use of C99 designated initialisers for nulls/values arrays".
That started off with lots of support, but then there was a suggestion
that the {0} should be implemented as a macro, and the subsequent
discussions about that macro eventually bikeshedded the patch to
death.

It might be a good idea if you check that old thread so you can avoid
the same pitfalls. I hope you have more luck than I did ;-)
I see, thanks.
We are using only {0}, just to avoid these pitfalls.
All changes here are safe, because, the tradeoff is

MemSet with 0 to {0}

Any else is ignored.

The rest of the calls with MemSet are alignment and padding dependent, and for now, will not be played.

regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Perform streaming logical transactions by background workers and parallel apply
Next
From: Tom Lane
Date:
Subject: Re: Add proper planner support for ORDER BY / DISTINCT aggregates