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 <mich...@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-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to