Re: Slowdown around 5.0.5-dev-0

[Bart Schaefer <schaefer@brasslantern.com>]

On Oct 11,  6:48pm, Sebastian Gniazdowski wrote:
} 
} It's now much faster, zprof time 11851 vs 3433. That's still strongly
} lagging behavior. One other trait is that it slows down after a while.

The whole algorithm is designed to maximally fill the allocated space
and thereby minimize the memory footprint, not to maximize speed.  So
the more often you grow/free the heap, the more time it spends looking
for unused space in the existing arenas.

Besides zprof, it would be interesting to see the maximum memory usage
of the patched and unpatched shells.

Does this change in zhalloc() make any difference?  This goes farther
in the direction of abandoning small bits of earlier arenas until the
popheap() comes around.

diff --git a/Src/mem.c b/Src/mem.c
index b9569ea..63a5afe 100644
--- a/Src/mem.c
+++ b/Src/mem.c
@@ -543,9 +543,14 @@ zhalloc(size_t size)
 
     /* find a heap with enough free space */
 
-    for (h = ((fheap && ARENA_SIZEOF(fheap) >= (size + fheap->used))
-	      ? fheap : heaps);
-	 h; h = h->next) {
+    /*
+     * This previously assigned:
+     *   h = ((fheap && ARENA_SIZEOF(fheap) >= (size + fheap->used))
+     *	      ? fheap : heaps);
+     * but we think that nothing upstream of fheap has more free space,
+     * so why start over at heaps just because fheap has too little?
+     */
+    for (h = (fheap ? fheap : heaps); h; h = h->next) {
 	if (ARENA_SIZEOF(h) >= (n = size + h->used)) {
 	    void *ret;