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

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

On Thu, Aug 12, 2010 at 4:25 PM,  <st...@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?

-Hyrum

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

[Stefan Fuhrmann <st...@alice-dsl.de>]

On 14.10.2010 21:45, Hyrum K. Wright wrote:
> On Thu, Aug 12, 2010 at 4:25 PM,<st...@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.