malloc行为如何避免堆碎片？

答案是仔细的编程。否则碎片化是不可避免的。



      以下为原文

    The answer is careful programming. Otherwise fragmentation is inevitable.

任何堆策略都有点推测，因为策略是固定的，而应用程序变化很大。在参考线程不合理的情况下，我没有发现策略（尽管XC32 1.20可能在元素@ 400似乎丢失时暴露出一些bug…堆分配必须解决2个问题：当请求这样做时，提供“任何”（合理的）内存量。这样做快。我希望“老”C32策略总体上更慢，而不一定更好。用户没有尝试（但我推荐）：以前一个（）的倒序（F1）、P2、P3的顺序（For）。P4应该导致P4、P3、P2、P1的自由（）序列。尽管堆策略可能有所不同，但我希望这个序列具有最高的可能性来获得一些性能良好的堆，以最小的碎片。



      以下为原文

    Any heap strategy is somewhat speculative as the strategy is fixed while the application programs vary greatly.
I do not find the strategies in the referred thread unreasonable (although XC32 1.20 might expose some bug when the Element @ 400 seems to get lost...
 
Heap allocation has to solve 2 issues:

• Provide "any" (reasonable) amount of memory when requested to do so.
  
• Do this fast.
  

I'd expect the "old" C32 strategy to be slower overall and not necessarily better.
What the user didn't try (but what I'd recommend): to free() in reverse order of the previous alloc().
 
An alloc() sequence of p1, p2, p3, p4  should result in a free() sequence of p4, p3, p2, p1.
Although heap strategies might vary, I'd expect this sequence to have the highest likelihood to get some well-performing heap with minimum fragmentation.

如果分配相同大小的所有内容，堆不会碎片。否则，避免碎片化的唯一方法是有一个大堆（大约3X倍的需要）。



      以下为原文

    If you allocate everything of the same size, the heap will not fragment. Otherwise, the only way to avoid fragmentation is to have a big heap (roughly 3x times of what is needed).

“NothGuyIf”等于“碎片化”，“把一些大块分割成更小的块”，任何一个（）都会留下一个碎片。除非这个片段连接到一个相邻的未使用的块，否则它是一个片段。我同意，如果你只分配一些恒定大小的块，这基本上没有关系（如果内存可用的话，块是可用的）。但是，当涉及到动态块大小（曾经调试过一些C++字符串连接操作时）？如果你得到的是不同大小的块，那么如果空闲序列（不是自由顺序），则加入自由块可能花费很多时间，或者可能仍然不完美（例如如果2个空闲块之间的块是空闲的）。这是一个关于缓存配置对机器性能影响的复杂话题。最近，我对这些“事物”（缓存、堆和其他主题）的判断开始广泛发布。



      以下为原文

    @ NothGuy
If you equate "fragmenting" with "splitting some big block into smaller ones", any free() will leave a fragment. Unless this fragment is joint to an adjacent unused block, it is a fragment.
I agree that this basically doesn't matter if you allocate only blocks of some constant size (as such a block is available if memory is available at all). But when it comes to dynamic block sizes (ever debugged some C++ string catenation operation stepping into?), you'll get blocks of varying sizes allocate()'d and free()'d again.
If the sequence of free() is not the reverse order of the allocate()'s, likelihood is high that joining free block might either take a lot of time or might remain imperfect (e.g. if a block between 2 free blocks is free()'d).
 
Anyway: this is a topic about as complex as the influence of cache configuration on machine performance.
It's just recently that my own judgement on these "things" (cache, heap and some other topics) starts to get widely published.

我确实做了大量的分配和释放。（我使用的是和声1.09）128K RAM，大约30到40K的工作。在启动时分配了两个大的块（TCP/IP 40K和TLS的20K）。TLS的20 K可以在稍后的时刻释放，如果配置显示我不需要TLS，剩下的是大约100个字节或更少的分配，有时是5K。这些分配是短暂的。在整个运行时保持的分配在很早的阶段完成（在读取配置）。在那之后，我有数百万（是的，我数了）分配和自由，他们从不停止。长话短说：我没有任何问题。Nick。



      以下为原文

    I do make massive allocs and frees.
(I'm using Harmony 1.09)
Of the 128k RAM, at about 30 to 40k are left to work with.
There are two big chunks (40k for TCP/IP and 20k for TLS) that are allocated at startup. The 20 k for TLS might be freed at a later moment, if the configuration shows that I don't need TLS.
The rest are allocs of around 100 bytes or less, sometimes 5k.
These allocs are short lived. Allocs that are kept over the whole runtime are done in a very early stage (at reading the configuration). After that, I do have millions (yes, I counted them) of allocs and frees and they never stop.
 
Long talk short: I don't have any problems.
 
Nick
 
 

如果你正在谈论图形堆栈，它立刻释放屏幕上的所有数据。当事情在随机的时候举行和发布时，这个问题就变得至关重要。



      以下为原文

    If you are talking about the graphic stack, it frees all the data for the screen at once. The issue becomes critical when things are held and released at random times.