On Fri, Aug 1, 2014 at 4:44 PM, Branko Čibej <br...@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.
