On Tue, Jun 24, 2014 at 11:04 AM, Stefan Sperling <stsp_at_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.
Received on 2014-06-24 23:19:09 CEST