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,<stefan2_at_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.
Received on 2012-03-05 00:23:26 CET