MQX内存管理的缺陷-申请大量内存块后释放速度会变慢
我们的实际应用中需要申请大量的内存块,内存块大小不同,这时如果要释放其中的某一个内存块,需要很长时间而且这段时间是无法响应中断的,严重影响了产品。我学习了下MQX关于内存管理这部分的代码,发现MQX将申请的内存块作为一个单向链表,释放时每次都遍历很长时间才能找到需要释放的内存块,而且这期间代码
内有明确的关中断。不知道其他坛友是否也碰到过这个问题?
这部分代码我自己修改了部分,减少了遍历时间,但是感觉MQX在内存管理部分有些混乱,官方是不是考虑更新一下。 ”需要很长时间而且这段时间是无法响应中断的“,这确实是一个问题。 会跑的多慢?? sblpp 发表于 2014-11-7 12:05
会跑的多慢??
从LZ描述看,并不是一直慢,而是释放内存的时间过长,且关了中断,相当于“假死机”。 你自己写个内存池不得了。高性能应用向来都是用内存池。 楼主用的内存释放方法是不是官方例程中用的呢?预计还是释放的方法问题,如果要真是硬件问题估计FSL这一个系列都会有问题,但是觉得不可能。最大有可能是库函数支持问题。 要是在空闲时间释放呢? fengyunyu 发表于 2014-11-7 12:26
从LZ描述看,并不是一直慢,而是释放内存的时间过长,且关了中断,相当于“假死机”。 ...
对,我看了看我们需要释放近8000个内存块,需要等很长时间其他任务才会执行,因为定时器中断无法响应了 官方自带了很多内存使用方法,自己开辟内存池自己管理是种方法,我们也考虑过了,也实现了这种方法 “需要很长时间而且这段时间是无法响应中断的”,这样的话几乎算是不能用
楼主可以参考ucos的存储管理 用户代码对内存的使用最好具有特定的模式,然后自己有针对性的实现一个内存分配器。
通用的内存分配器总会在实现的时候有取舍;据说实时系统效率比较高的是TLSF那个分配器。
wxfje 发表于 2014-11-7 20:30
“需要很长时间而且这段时间是无法响应中断的”,这样的话几乎算是不能用
楼主可以参考ucos的存储管理 ...
只是在分配和释放大量内存块(多于1万个)时会这样 5楼正解!还有,有时候可以将任务栈做大一点,直接用局部变量!速度会快一些! 可以改写内存管理算法,用红黑树的话,效率能提高很多的。具体参考以前Linux内核的内存管理做法,除了红黑树外,还要考虑内存块的合并。 0flame0 发表于 2014-11-10 08:13
只是在分配和释放大量内存块(多于1万个)时会这样
这样的话,就只能改写算法了。我在应用中还没碰到需要用这么多的
页:
[1]