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

Re: svn commit: r984984 - /subversion/branches/performance/subversion/libsvn_repos/reporter.c

From: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Sun, 24 Oct 2010 21:56:25 +0200

On 14.10.2010 21:45, Hyrum K. Wright wrote:
> On Thu, Aug 12, 2010 at 4:25 PM,<stefan2_at_apache.org> wrote:
>> Author: stefan2
>> Date: Thu Aug 12 21:25:11 2010
>> New Revision: 984984
>>
>> URL: http://svn.apache.org/viewvc?rev=984984&view=rev
>> Log:
>> Eliminate redundant revprop lookups: Exports / checkouts often
>> contain multiple nodes from the same revision. Therefore, we
>> cache essential revision info in the report baton for as long as
>> the report is running.
>>
>> As a neat side-effect, this will also fix inconsistencies created by
>> changing revprops (in a parallel request) while a report is running.
> A nice change. In reviewing it for merge to trunk, I noticed that
> cached information is never evicted. Do we assume that the number of
> revisions touched won't be significant, so we don't need to worry
> about the size of the cache (and hence memory usage) blowing up?
>
For all real-world reports, that is not a problem because
they hardly span more than a few thousand revisions
(which is the whole point of the optimization). Even when
exporting *all* of apache.org (all tags, branches etc.) in
a single request, the memory went up by only a few MB.

If we want to be very paranoid, we could clean the cache
before adding the, say, 10000th entry. To do that, we
need just another pool in the baton to hold the cache
and its entry in a disposable chunk of memory.

-- Stefan^2.
Received on 2010-10-24 21:57:57 CEST

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.