You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ivan Zhakov <iv...@visualsvn.com> on 2014/08/04 14:22:58 UTC
Re: svn commit: r1615458 - /subversion/branches/authzperf/subversion/libsvn_repos/log.c
On 4 August 2014 02:47, <st...@apache.org> wrote:
> Author: stefan2
> Date: Sun Aug 3 22:47:07 2014
> New Revision: 1615458
>
> URL: http://svn.apache.org/r1615458
> Log:
> On the authzperf branch: Speed up authz-aware 'svn log' by sorting the
> paths before checking them. This lets the recent O(1) authz lookup
> optimization for sibbling paths kick in.
>
> * subversion/libsvn_repos/log.c
> (check_changed_path): Factored out loop content of ...
> (detect_changed): ... this. Use sorted iteration when applying authz.
>
Stefan,
Could you please confirm after that commit repository layer will do
more (sort changed path) assuming that particular authz check function
will work faster if calls will come in sorted order?
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: svn commit: r1615458 - /subversion/branches/authzperf/subversion/libsvn_repos/log.c
Posted by Branko Čibej <br...@wandisco.com>.
On 04.08.2014 16:30, Ivan Zhakov wrote:
> On 4 August 2014 17:43, Branko Čibej <br...@wandisco.com> wrote:
>> On 04.08.2014 14:22, Ivan Zhakov wrote:
>>
>> On 4 August 2014 02:47, <st...@apache.org> wrote:
>>
>> Author: stefan2
>> Date: Sun Aug 3 22:47:07 2014
>> New Revision: 1615458
>>
>> URL: http://svn.apache.org/r1615458
>> Log:
>> On the authzperf branch: Speed up authz-aware 'svn log' by sorting the
>> paths before checking them. This lets the recent O(1) authz lookup
>> optimization for sibbling paths kick in.
>>
>> * subversion/libsvn_repos/log.c
>> (check_changed_path): Factored out loop content of ...
>> (detect_changed): ... this. Use sorted iteration when applying authz.
>>
>> Stefan,
>>
>> Could you please confirm after that commit repository layer will do
>> more (sort changed path) assuming that particular authz check function
>> will work faster if calls will come in sorted order?
>>
>>
>> That's the general idea, yes; authz lookups should be MUCH faster with the
>> new in-memory representation, and the representation will work best with
>> in-order sequences of queries. Note that there is no semantic change for
>> existing authz files.
>>
> I don't like such implicit coupling between layers for improving
> performance. It will be very fragile optimization and could break in
> future making performance worse than before.
Eh? How else do you propose to improve performance within a single
module? The authz support is completely private to libsvn_repos.
The purpose of the authzperf branch is not only to add wildcards to
authz rules, but to speed up log &co., operations that are heavily
affected by authz performance. It turns out that part of the fix is
inventing smarter strategies for lookups into authz info. These /have/
to somehow affect the implementation bits of libsvn_repos outside the
authz module, since otherwise they wouldn't be used.
Once more, all these connections are completely private to libsvn_repos;
there is no change in the any public API. Other than adding new rule
syntaxes to authz files that are currently invalid and therefore never used.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane@wandisco.com
Re: svn commit: r1615458 - /subversion/branches/authzperf/subversion/libsvn_repos/log.c
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 4 August 2014 17:43, Branko Čibej <br...@wandisco.com> wrote:
> On 04.08.2014 14:22, Ivan Zhakov wrote:
>
> On 4 August 2014 02:47, <st...@apache.org> wrote:
>
> Author: stefan2
> Date: Sun Aug 3 22:47:07 2014
> New Revision: 1615458
>
> URL: http://svn.apache.org/r1615458
> Log:
> On the authzperf branch: Speed up authz-aware 'svn log' by sorting the
> paths before checking them. This lets the recent O(1) authz lookup
> optimization for sibbling paths kick in.
>
> * subversion/libsvn_repos/log.c
> (check_changed_path): Factored out loop content of ...
> (detect_changed): ... this. Use sorted iteration when applying authz.
>
> Stefan,
>
> Could you please confirm after that commit repository layer will do
> more (sort changed path) assuming that particular authz check function
> will work faster if calls will come in sorted order?
>
>
> That's the general idea, yes; authz lookups should be MUCH faster with the
> new in-memory representation, and the representation will work best with
> in-order sequences of queries. Note that there is no semantic change for
> existing authz files.
>
I don't like such implicit coupling between layers for improving
performance. It will be very fragile optimization and could break in
future making performance worse than before.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: svn commit: r1615458 - /subversion/branches/authzperf/subversion/libsvn_repos/log.c
Posted by Branko Čibej <br...@wandisco.com>.
On 04.08.2014 14:22, Ivan Zhakov wrote:
> On 4 August 2014 02:47, <st...@apache.org> wrote:
>> Author: stefan2
>> Date: Sun Aug 3 22:47:07 2014
>> New Revision: 1615458
>>
>> URL: http://svn.apache.org/r1615458
>> Log:
>> On the authzperf branch: Speed up authz-aware 'svn log' by sorting the
>> paths before checking them. This lets the recent O(1) authz lookup
>> optimization for sibbling paths kick in.
>>
>> * subversion/libsvn_repos/log.c
>> (check_changed_path): Factored out loop content of ...
>> (detect_changed): ... this. Use sorted iteration when applying authz.
>>
> Stefan,
>
> Could you please confirm after that commit repository layer will do
> more (sort changed path) assuming that particular authz check function
> will work faster if calls will come in sorted order?
That's the general idea, yes; authz lookups should be MUCH faster with
the new in-memory representation, and the representation will work best
with in-order sequences of queries. Note that there is no semantic
change for existing authz files.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane@wandisco.com