0flame0 发表于 2014-11-7 11:28:22

MQX内存管理的缺陷-申请大量内存块后释放速度会变慢

我们的实际应用中需要申请大量的内存块，内存块大小不同，这时如果要释放其中的某一个内存块，需要很长时间而且这段时间是无法响应中断的，严重影响了产品。
我学习了下MQX关于内存管理这部分的代码，发现MQX将申请的内存块作为一个单向链表，释放时每次都遍历很长时间才能找到需要释放的内存块，而且这期间代码
内有明确的关中断。不知道其他坛友是否也碰到过这个问题？
这部分代码我自己修改了部分，减少了遍历时间，但是感觉MQX在内存管理部分有些混乱，官方是不是考虑更新一下。

fengyunyu 发表于 2014-11-7 11:55:30

”需要很长时间而且这段时间是无法响应中断的“，这确实是一个问题。

sblpp 发表于 2014-11-7 12:05:47

会跑的多慢？？

fengyunyu 发表于 2014-11-7 12:26:23

sblpp 发表于 2014-11-7 12:05
会跑的多慢？？

从LZ描述看，并不是一直慢，而是释放内存的时间过长，且关了中断，相当于“假死机”。

wye11083 发表于 2014-11-7 13:03:21

你自己写个内存池不得了。高性能应用向来都是用内存池。

步之道 发表于 2014-11-7 15:41:43

楼主用的内存释放方法是不是官方例程中用的呢？预计还是释放的方法问题，如果要真是硬件问题估计FSL这一个系列都会有问题，但是觉得不可能。最大有可能是库函数支持问题。

步之道 发表于 2014-11-7 15:45:23

要是在空闲时间释放呢？

0flame0 发表于 2014-11-7 16:48:24

fengyunyu 发表于 2014-11-7 12:26
从LZ描述看，并不是一直慢，而是释放内存的时间过长，且关了中断，相当于“假死机”。 ...

对，我看了看我们需要释放近8000个内存块，需要等很长时间其他任务才会执行，因为定时器中断无法响应了

0flame0 发表于 2014-11-7 16:50:56

官方自带了很多内存使用方法，自己开辟内存池自己管理是种方法，我们也考虑过了，也实现了这种方法

wxfje 发表于 2014-11-7 20:30:47

“需要很长时间而且这段时间是无法响应中断的”，这样的话几乎算是不能用
楼主可以参考ucos的存储管理

dr2001 发表于 2014-11-7 20:37:42

用户代码对内存的使用最好具有特定的模式，然后自己有针对性的实现一个内存分配器。

通用的内存分配器总会在实现的时候有取舍；据说实时系统效率比较高的是TLSF那个分配器。

0flame0 发表于 2014-11-10 08:13:04

wxfje 发表于 2014-11-7 20:30
“需要很长时间而且这段时间是无法响应中断的”，这样的话几乎算是不能用
楼主可以参考ucos的存储管理 ...

只是在分配和释放大量内存块（多于1万个）时会这样

wangpengcheng 发表于 2014-11-10 09:27:34

5楼正解！还有，有时候可以将任务栈做大一点，直接用局部变量！速度会快一些！

twitter 发表于 2014-11-10 10:42:25

可以改写内存管理算法，用红黑树的话，效率能提高很多的。具体参考以前Linux内核的内存管理做法，除了红黑树外，还要考虑内存块的合并。

wxfje 发表于 2014-11-10 21:17:14

0flame0 发表于 2014-11-10 08:13
只是在分配和释放大量内存块（多于1万个）时会这样

这样的话，就只能改写算法了。我在应用中还没碰到需要用这么多的
页: [1]
查看完整版本: MQX内存管理的缺陷-申请大量内存块后释放速度会变慢