TI中文支持网我们自己开发的缩放算法，在算法内部统计耗时只有20ms，但是在arm侧的应用层统计调用算法的耗时达到了25ms，请问有没有办法把算法调用的时间减少？
bin feng：
系统中同时还有其他调用，音频编解码、混音、视频编解码等，还有输入输出、网口，是不是因为音频调用频繁影响到了视频调用消息传递的及时性？
Coolen Xue：
我遇到过类似的问题。有几个想法，你可以参考一下。
1，dsp侧算法运行的过程中，如果arm或其他master上，并行的进行着频繁的访存操作，会对dsp侧算法的耗时影响非常大，单独测试时耗时20ms的算法，被恶化到25ms、30ms也有可能。所以，你最好，能把系统中其他工作剥离掉，单独对算法做个测试，看看是codec engine的调用负载造成的，还是系统中其他部分的影响造成的。
2，就我们开发中看到的现象来说，不论是音频的编解码，还是codec engine调用，对dsp上算法性能的影响都不是太大。应该不会超过10%.
3, codec engine进行arm与dsp之间的协同，所花费的时间，你可以参考
processors.wiki.ti.com/…/Codec_Engine_Overhead
中multi-core overhead部分的说明，主要是cache一致性的维护花了时间，但你这个情况，也不会超过1ms.
4,你这个测算时间的方法，其实我没有搞太明白。你的算法内部耗时是如何测出来的，用ccs吗？这个20ms与25ms是对同一次运行进行测试，得出来的结果吗？
bin feng：
回复 Coolen Xue:
1.系统中存在着频繁访存操作，因为编码需要发送网络包，解码需要接收网络包，虽然6467的scr设计中emac不会影响到ddr2，但是系统中还要做一些depayload等操作，也就是会有很多memcpy/memmove，这些确实影响到了算法耗时，因为在只做编解码自环的时候，没有那些对网络数据的处理，耗时跟在DSP统计的耗时相差不大；如果真实场景需要处理网络数据，则耗时会增加很多，就是你说的从20ms到25、30ms，但是在DSP统计的耗时跟之前并没有显著的增加为22ms左右，所以怀疑是因为codec engine的调用不及时了，我们是借用的viddec2的接口，需要返回很多参数(IVIDDEC2_OutArgs)，1900多字节，这个明显偏多，如果还仍然使用viddec2接口，把返回的参数字节数加倍，会发现其对整个系统有非常严重的影响，但我做了实验改为viddec接口，参数字节数为180字节，发现耗时会有一点点降低；
2.确实有音频的情况下，对视频算法影响很小，应该是音频本身数据量偏小，虽然频度比视频高；
3.现在怀疑是因为任务优先级的原因，算法作为一个任务在dsp上跑，那么它的消息发送和接收也受到优先级的影响？
4.算法耗时在DSP有统计(离开和进入process函数之间的时间插值)在ARM也有统计，之间的插值就认为是codec engine层消耗掉的；20和25ms是个平均值，2s统计一次均值，然后多次观察的平均值；
Coolen Xue：
回复 bin feng:
1，如果说调用的时间，跟返回的参数字节数有关，那看起来，可能就真的是codec engine本身消耗掉了。你可以看下我发你的那个计算multi-core codec engine overhead的wiki。 但是我们之前按wiki计算出的值，跟我们系统里测得的实际情况，也差别很大。
2，我们也怀疑过跟线程调度有关，后来优化过一段时间，没有明显改进。
3，如果25ms确实满足不了你们的性能要求，你们可以考虑抛开codec engine,直接使用底层的DspLink接口，这样虽然难度稍大一些，但是可以消除掉codec engine带来的一些不明不白的性能消耗。据说，比较有研发实力的，全都是直接用的DspLink.
Coolen Xue：
回复 Coolen Xue:
如果最后确认是任务优先级，或其他方面的原因，麻烦你告诉我一声，我们当时是采用其他方式把这个问题规避了，到现在，还有些问题没有搞清楚。
bin feng：
回复 Coolen Xue:
不太方便修改DSPLINK的接口，那样对整个系统的修改太多了，因为视频算法都要使用片内共享内存的原因，需要做好互斥，调整优先级的话只能把算法的优先级也调整了，影响到音频任务了，你是怎么规避的？
Feng Dong：
回复 bin feng:
有个老版本的dsplink有该问题,请用最新的试试.
bin feng：
回复 Feng Dong:
谢谢，你真的是雪中送炭，能不能说明下是那个版本？我们现在用的是1.50，dvsdk是1.4
Feng Dong：
回复 bin feng:
e2e.ti.com/…/683690.aspx
有关讨论见上面帖子的链接.你的版本是在太老,建议整体用新的dvsdk.另外多core之间通讯ms级别的开销是正常的.
不知道你们用的6467是594还是729,如果升级到新的dvsdk不能解决问题,还是要升级到高主频的版本比如6467T
Coolen Xue：
回复 Feng Dong:
这是最新的DVSDK_3_10_00 3_10_00_19
software-dl.ti.com/…/index_FDS.html
我们当时从1.4升级到这个版本以后，系统性能提高了很多。它的编码器与hdvicp的库也更新了，编码性能提高了不少。
