On Tue, Jun 24, 2014 at 11:04 AM, Stefan Sperling <s...@elego.de> wrote:
> On Tue, Jun 24, 2014 at 12:50:52AM +0200, Stefan Fuhrmann wrote: > > The serializer itself uses a single, auto-growing buffer. > > It should show up as a temporary peak, though. > > There is a peak roughly above 200MB before the log message > is printed. It then settles at 173MB for me. > > > The current 100 bytes estimation / change is way to low > > with the basic struct already taking 144 bytes on a 64bit > > system. r1604947 should help here. > > It doesn't seem to help me, unfortunately. > I'm still seeing 173MB of memory in top(1) while the changed > paths list is printed and it goes down from there when the > process exits. Do you see something else? > r1604947 only helps with the temp. peak during serialization in a scratch pool. > > > Does anyone know what can be done about this? > > > > > > > Use a similar estimate as in r1604947 to skip svn_cache__set > > for uncachable items (call svn_cache__is_cachable). > > > > As soon as I arrived in UK, I'll look into this. > > Thanks! I appreciate your help with this. > On my system, I'm now (r1605195) at 46MB peak, 55MB when I disable the cache bypass of r1605191. Lower usage is possible but requires a completely different, streaming, API. -- Stefan^2.
