The patch (alone) much helped, zprof time is now 3027 and there is no
after-while slow down. Htop shows RES of 152 MB. For the first patch
RES is 166 MB. For the clean version it's 152 MB. I didn't combine the
patches (BTW. the problems with applying patches were caused by expand
tabs that occured on copy-pasting).


On 11 October 2015 at 19:31, Bart Schaefer <schaefer@brasslantern.com> wrote:
> 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;
>