On Tue, Nov 3, 2015 at 7:56 PM, Rostislav Pehlivanov
wrote:
> The binary increase is 16 kbytes per file * 2 (since it's a template for
> the fixed and float decoders) = 32 kbytes. This is not very significant at
> all, even for the most memory and storage-space constrained (with an MMU)
> device.
The binary increase is 16 kbytes per file * 2 (since it's a template for
the fixed and float decoders) = 32 kbytes. This is not very significant at
all, even for the most memory and storage-space constrained (with an MMU)
device. (not to mention that this is using the default compiler
optimizations
On Tue, Nov 3, 2015 at 3:24 PM, Rostislav Pehlivanov
wrote:
> LGTM.
> Tested the patch, doesn't change the output.
I am personally fine with this, but was hoping for an opinion on
whether the perf increase here is important enough to justify the
binary size increase. Hence my ping to the AAC peop
LGTM.
Tested the patch, doesn't change the output.
On 28 October 2015 at 01:38, Ganesh Ajjanagadde
wrote:
> When sbr->reset is set in encode_frame, a bunch of qsort calls might get
> made.
> Thus, there is the potential of calling qsort whenever the spectral
> contents change.
>
> AV_QSORT is su
On Tue, Oct 27, 2015 at 9:38 PM, Ganesh Ajjanagadde
wrote:
> When sbr->reset is set in encode_frame, a bunch of qsort calls might get made.
> Thus, there is the potential of calling qsort whenever the spectral
> contents change.
>
> AV_QSORT is substantially faster due to the inlining of the compa
When sbr->reset is set in encode_frame, a bunch of qsort calls might get made.
Thus, there is the potential of calling qsort whenever the spectral
contents change.
AV_QSORT is substantially faster due to the inlining of the comparison callback.
Thus, the increase in performance should be worth the
