[FFmpeg-devel] [PATCH 3/8] avutil/mem: Add av_fast_realloc_array()

Andreas Rheinhardt andreas.rheinhardt at outlook.com
Mon Sep 26 17:21:39 EEST 2022


Andreas Rheinhardt:
> Anton Khirnov:
>> Quoting Andreas Rheinhardt (2022-07-14 14:51:07)
>>> Anton Khirnov:
>>>> Quoting Andreas Rheinhardt (2022-07-12 16:12:16)
>>>>> Anton really dislikes the av_fast_* naming and instead wants this to be
>>>>> called av_realloc_array_reuse(). I don't care either way. Any more
>>>>> opinions on this (or on the patch itself)?
>>>>
>>>> If people dislike _reuse(), I am open to other reasonable suggestions.
>>>> This 'fast' naming sucks because
>>>> - it tells you nothing about how this function is "fast"
>>>> - it is added at the beginning rather than the end, which is
>>>>   against standard namespacing conventions
>>>>
>>>
>>> Isn't reusing the basic modus operandi for a reallocation function? So
>>> your suggested name doesn't seem to fit either.
>>
>> Ordinary realloc just keeps the data, I wouldn't call that "reuse" since
>> it will often be a copy. This "fast" realloc OTOH reuses the actual
>> buffer, same as all the other "fast" mem.h functions.
>>
>> But feel free to suggest another naming pattern if you can think of one.
>>
> 
> I see two differences between this function and ordinary realloc: It
> never shrinks the buffer and it overallocates. These two properties make
> it more likely that these functions can avoid copies more often than
> plain realloc (but in contrast to realloc, we can not grow the buffer in
> case there is free space after it), but it is nevertheless the same as
> realloc.
> 
> But I don't really care that much about the name and will therefore use
> your name as I can't come up with anything better.
> (Of course, I am still open to alternative suggestions.)
> 

Here is a rebased branch that uses av_realloc_array_reuse:
https://github.com/mkver/FFmpeg/commits/fast_realloc

- Andreas



More information about the ffmpeg-devel mailing list