On 04.03.2012 11:06, Daniel Shahaf wrote:
Hyrum K Wright wrote on Sat, Mar 03, 2012 at 09:51:07 -0600:
On Sat, Mar 3, 2012 at 5:31 AM,<stef...@apache.org> wrote:
Author: stefan2
Date: Sat Mar 3 11:31:17 2012
New Revision: 1296604
URL: http://svn.apache.org/viewvc?rev=1296604&view=rev
Log:
Certain operations, e.g. svn ls, will contain timestamp and author
information from many different revisions. A list of all projects
in the root of the wordpress repository will open, read and close
75.000 revision property files (3 reads for each list entry)
This commit implements revprop caching. It will be activated as
part of the full-text caching option.
Since revprops may be written by other threads or processes, we
need to track the revprop changes. A new special file contains a
counter that will be increased each time revision properties get
rewritten.
This counter is internally called "revprop generation" and will be
read upon the first revprop access for given fs_t. Later changes
may remain invisible for that fs_t. This behavior is in line with
our revprop handling in other parts of FS_FS. If a revprop gets
rewritten, the fs_t doing the write will use the new generation
from that point on and will thus see all caches up to and including
its own.
Since the revprop generation becomes part of the cache key, each
fs_t will only see revprops from its generation. It may also
create new cache entries tagged with that generation, i.e. those
would appear to be outdated for newer fs_t. But that will simply
cause a benign false negative upon lookup. No fs_t will see
data that got replaced before that fs_t was created.
How does this potentially interact with revprop packing?
I believe the two features are orthogonal.
Yes, they can be treated as being independent --
apart from the occasional merge conflict. Revprop
caching simply hooks the revprop read and write
functions.
Since packed revprops come as larger files, a naive
implementation (read revprop -> open packed file,
read just one revprop, close file) would be even
slower than on trunk, some sort of caching is in
order keep performance acceptable.
Revprop caching could come in quite handy here:
read packed file, parse & cache *all* revpros therein,
close file. Most redundant reads will now be eliminated.
-- Stefan^2.
