diff options
author | Ganesh Ajjanagadde <gajjanagadde@gmail.com> | 2015-10-17 21:22:59 -0400 |
---|---|---|
committer | Ganesh Ajjanagadde <gajjanagadde@gmail.com> | 2015-10-18 09:22:49 -0400 |
commit | e11e32686fdb21aded1ccf70202f1fffe87bb6a2 (patch) | |
tree | fe5eafdc561ababcf7c3658707259fa840d46514 /.travis.yml | |
parent | 9496f565dcc7b5ec5d8d118e492a0637c15617da (diff) | |
download | ffmpeg-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