On Fri, Aug 1, 2014 at 4:44 PM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 01.08.2014 14:49, Stefan Fuhrmann wrote:
>
> [...]
>
> * The filtered tree can be constructed more quickly if the
> path rules are usually in path-order, i.e. there will soon be
> a shortcut that works for sibling paths. Once more, iteration
> in sorted or original file order would be a good thing here.
>
>
> Currently the array of ACLs (which includes paths) is in file order, and I
> stole your idea of storing a sequence number in the ACL. It should be
> trivial to add another array that sorts the same ACLs in path order. I
> suspect you want the path order to ignore repository names in the rules,
> right?
>
Declaration order is just fine. Hash order would not.
I suppose that sorting, in particular with a complicated
criterion, would be more expensive than once in a while
not having a O(1) insert. Even more so as many path
rules may be irrelevant to the current user.
> BTW, I was thinking about storing the paths pre-parsed, as an array of
> path segments with indicators on each segment if it's a pattern match or
> not. I expect this would make constructing the filtered rules even easier
> (and faster and less memory-intensive).
>
Not splitting the path would probably be faster. The idea
is to use the parent of the previously added path as a
hint for the next insertion. So, having the plain path should
cause less headache and splitting the remainder into segments
should be cheap - if at all necessary.
-- Stefan^2.
Received on 2014-08-01 18:51:33 CEST