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 > issue. > > 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. Thank's. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
