[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Progress on issue 1964 (mem leak on commit)

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-09-07 07:09:23 CEST

On Mon, 2004-09-06 at 16:38, Erik Huelsmann wrote:
> libsvn_client and
> libsvn_wc don't seem to be among those libraries. From what I've seen
> making them streamy (or at least some operations) might be the only solution
> to limiting memory use on commit (and add and others?).

If we only store the names of the commit targets in memory, we should be
okay. At 50 or so bytes per commit target, we only spend a meg for each
20,000 targets.

So for practical purposes, we probably don't need to completely redesign
the commit process to be streamy. Such a redesign would be difficult,
as we store the list of commitables in memory in a number of
places--libsvn_ra_dav keeps a list; the editor driver holds onto file
batons for each file with text mods; svnserve also has to keep track of
file batons when receiving a commit editor drive.

But we do want to avoid reading the entire set of entries into memory,
and (if we aren't succeeding in this already) we want to avoid
allocating a pool per commit target, or allocating any temporary data in
the pools used to keep track of commit targets. I don't know how hard
that will be.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 7 07:09:52 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.