[FFmpeg-devel] [PATCH 15/23] dnn/dnn_backend_native_layer_conv2d: Join two arrays, avoid allocation

Guo, Yejun yejun.guo at intel.com
Fri Mar 12 10:03:11 EET 2021



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Andreas Rheinhardt
> Sent: 2021年3月12日 15:59
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 15/23]
> dnn/dnn_backend_native_layer_conv2d: Join two arrays, avoid allocation
> 
> Guo, Yejun:
> >
> >
> >> -----Original Message-----
> >>>> -----Original Message-----
> >>>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> >>>> Andreas Rheinhardt
> >>>> Sent: 2021年3月11日 5:55
> >>>> To: ffmpeg-devel at ffmpeg.org
> >>>> Cc: Andreas Rheinhardt <andreas.rheinhardt at gmail.com>
> >>>> Subject: [FFmpeg-devel] [PATCH 15/23]
> >>>> dnn/dnn_backend_native_layer_conv2d: Join two arrays, avoid allocation
> >>>>
> >>>> Fixes Coverity issue #1473507.
> >>>>
> >>>> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at gmail.com>
> >>>> ---
> >>>>  libavfilter/dnn/dnn_backend_native_layer_conv2d.c | 10 +++++-----
> >>>>  1 file changed, 5 insertions(+), 5 deletions(-)
> >>>>      }
> >>>>
> >>>>      //release memory
> >>>> -    av_freep(&thread_id);
> >>>> -
> >>>>      for (int i = 0; i < thread_num; i++){
> >>>>          av_freep(&thread_param[i]);
> >>>>      }
> >>>
> >>> LGMT, and just one question: shall we reduce the allocation as less as
> >> possible? thanks.
> >>>
> >> If it is doable without too much effort as is here, then the answer is
> >> yes. Actually, one could go even further than what this patchset did:
> >> One could keep the thread_param array instead of constantly allocating
> >> and freeing it. With much more effort, one could even keep the threads.
> >
> > thanks, and is the reason that: we need to check the return value for
> dynamic
> > allocation, and also need some effort to make sure to free it for all possible
> > paths in the code followed?
> >
> Yes, reducing the amount of allocations also reduces the amount of
> checks and frees one has to perform. You can see the latter in this
> patchset, namely in this patch and in the one that stopped allocating
> thread_param separately (which enabled to remove the loop for freeing them).

got it, thanks.


More information about the ffmpeg-devel mailing list