On Fri, Feb 9, 2018 at 6:12 PM, Nicolas George <geo...@nsup.org> wrote:
> Muhammad Faiz (2018-02-08):
>> I actually prefer _next() without introducing new API. Yeah, it is
>> slower because it must initialize next pointer
> I am not sure what you mean here. The problem with initing the next
> pointer was never speed.
> The problem with the next pointer is that it requires a run-time write
> in the codec structure, that requires it to be in the data section
> instead of the rodata section.
This is what I mean "speed" (Don't forget we also need to call
ff_thread_once on every _next() call).
> The static init of this pointer, as you proposed, fixes that specific
> But that is still a linked list. Linked lists are very good when you
> need to insert and remove in the list frequently, but for something that
> is built once and then static, it has very limited usefulness.
I dislike that we introduce new API just because it is "slightly"
better than old API.
Also, migrating to new API isn't trivial enough (see cmdutils.c problem).
> If the drawback of memory management for solution C (returning the whole
> list at once) is considered too bad, then I think solution B is
> preferable: more versatile, easier to understand.
If we really need to introduce new API, I also choose B. (Unless we
have a plan to make
the array become linked list again in the future).
Actually, I don't care so much about this. I will follow what people agree.
> And by the way, until we decide between solutions A, B, C or anything
> else proposed, starting coding would be useless. Just as starting to
> pack your bags before deciding whether you go to the sea or mountain.
Except for fixing regression.
ffmpeg-devel mailing list