On Sat, Mar 12, 2016 at 12:09:13PM -0500, Ganesh Ajjanagadde wrote: > And yes, for me the proof of the pudding is in the eating. In other > words, if you or someone else sends a small, simple patch achieving > the above one-line change, I will be very happy and will learn > something.
Does that mean you did not see my patch, you did not consider it because it was not quite finished, or because it was still too complicated? > 3. Why do we even need all this hardcoded table chicanery? No one has > presented a use case where they make a serious difference, with > benches to support when I called for it wrt cbrt_tab and aac. Of > course it will be faster in many cases (e.g mpegaudio_tablegen still > takes 1M cycles down from 10M before), but by how much is really the > question. Ronald gave one related to numerous small files, but even > that was a stretch as one can batch process them together. The point is to avoid each table using up memory if you run hundreds of instances, reduce the attack surface for security issues by having more data in .rodata, and for platforms supporting it allow the tables to be stored and used directly from ROM, and even on normal platforms all them being swapped out to the binary instead of a swap file. That should mostly be useful for special platforms. But for some codecs the biggest: It makes things actually properly thread-safe instead of the hacks and luck we in some cases rely on to make initializing those table thread-safe/reliable. It is part of a plan B in case we ever need truly, 100% reliable thread safety without placing a significant number of functions under locks. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
