Re: [FFmpeg-devel] [PATCH 5/9] avcodec/vlc: Pass VLC_MULTI_ELEM directly not by pointer

[Leo Izen <leo.izen@gmail.com>]

On 10/23/23 12:04, Michael Niedermayer wrote:
> On Mon, Oct 23, 2023 at 02:10:35AM -0400, Leo Izen wrote:
>> On 10/22/23 17:51, Michael Niedermayer wrote:
>>> This makes the code more testable as uninitialized fields are 0
>>> and not random values from the last call
>>>
>>> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
>>> ---
>>>    libavcodec/vlc.c | 14 +++++++-------
>>>    1 file changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/libavcodec/vlc.c b/libavcodec/vlc.c
>>> index 9b7a42f79a3..4adec2da705 100644
>>> --- a/libavcodec/vlc.c
>>> +++ b/libavcodec/vlc.c
>>> @@ -356,7 +356,7 @@ static void add_level(VLC_MULTI_ELEM *table, const int is16bit,
>>>                          uint32_t curcode, int curlen,
>>>                          int curlimit, int curlevel,
>>>                          const int minlen, const int max,
>>> -                      unsigned* levelcnt, VLC_MULTI_ELEM *info)
>>> +                      unsigned* levelcnt, VLC_MULTI_ELEM info)
>>
>>
>> Is passing a struct by value advisable? Did you benchmark this? How does it
>> compare to memset(info, 0, sizeof(*info))?
> 
> The struct is 8 bytes, a pointer on 64bit arch is also 8byte
> 
> I did not benchmark, I think this code doesnt run that many iterations
> (when its not buggy), I mean each iteration adds a entry to the table
> and the table will normally be designed to fit in cache and its only
> for initializing.
> 
> do you still want me to bechmark this ?
> 
> thx
> 

If the struct is only 8 bytes it's probably not necessary.

- Leo Izen (Traneptora)

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".