Zsh Mailing List Archive
Messages sorted by:
Re: argv subscript range uses too many memory
- X-seq: zsh-workers 30808
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: argv subscript range uses too many memory
- Date: Tue, 20 Nov 2012 09:44:42 -0800
- Cc: Han Pingtian <hanpt@xxxxxxxxxxxxxxxxxx>
- In-reply-to: <121120090300.ZM5552@torch.brasslantern.com>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20121108084001.GA7594@localhost.localdomain> <email@example.com> <20121110105811.GA7136@localhost.localdomain> <121110065709.ZM4781@torch.brasslantern.com> <20121120130457.GD2500@localhost.localdomain> <121120090300.ZM5552@torch.brasslantern.com>
[Moved to zsh-workers; Han Pingtian Cc'd in case he's only on -users]
On Nov 20, 9:03am, Bart Schaefer wrote:
} Unfortunately as far as I can tell these two issues (the speed problem
} in last year's "the source of slow large for loops" thread and the space
} problem in this thread) are directly in conflict with one another. The
} speed problem requires that the heap not be fully garbage collected on
} every loop pass, but the space problem requires that it be collected at
} some point before the loop is done.
} Maybe there's a hybrid where freeheap() can examine the difference in
} position (fheaps - heaps) and do a full garbage collect only when the
} heap has become "too full".
On a moment's reflection that doesn't work directly because both heaps
and fheaps are pointers into a linked list, so they can't be differenced
that easily. Theoretically fheaps must always either be NULL or have a
value greater than or equal to heaps, but beyond that nothing forces
heap blocks to be in sequential pointer order, they could be returned by
malloc() in any arbritrary order.
So what we need is a fast way to estimate how much uncollected garbage
is in the heap -- or, conversely, a fast way to estimate how close we
are to running out of memory -- so that garbage collection can be put
off until it's necessary.
Or, as I said before, find a scope in which to pushheap/popheap ...
Barton E. Schaefer
Messages sorted by: