aboutsummaryrefslogtreecommitdiffstats
path: root/.travis.yml
diff options
context:
space:
mode:
authorGanesh Ajjanagadde <gajjanagadde@gmail.com>2015-10-17 21:22:59 -0400
committerGanesh Ajjanagadde <gajjanagadde@gmail.com>2015-10-18 09:22:49 -0400
commite11e32686fdb21aded1ccf70202f1fffe87bb6a2 (patch)
treefe5eafdc561ababcf7c3658707259fa840d46514 /.travis.yml
parent9496f565dcc7b5ec5d8d118e492a0637c15617da (diff)
downloadffmpeg-e11e32686fdb21aded1ccf70202f1fffe87bb6a2.tar.gz
avcodec/bitstream: replace qsort with AV_QSORT
Commit 3a0a2f33a6c955823fa4fb12c0b49cd29a496659 claims large performance advantages for AV_QSORT over libc's qsort. The reason is that I suspect that libc's qsort (at least on non LTO builds, like the typical FFmpeg config) can't inline the comparison callback: https://stackoverflow.com/questions/5290695/is-there-any-way-a-c-c-compiler-can-inline-a-c-callback-function. AV_QSORT has two things going for it: 1. The guaranteed inlining of qsort itself. This yields a negligible boost that may be ignored. 2. The more serious possibility of potentially allowing the comparison function to be inlined - this is likely responsible for the large boosts reported. There is a comment explaining that this is a place that could use some performance improvement. Thus AV_QSORT is used to achieve that. Benchmarks deemed unnecessary due to existing claims about AV_QSORT. Tested with FATE. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Diffstat (limited to '.travis.yml')
0 files changed, 0 insertions, 0 deletions