Re: svn commit: r1614052 - in /subversion/branches/authzperf/subversion/libsvn_repos: authz.c authz_pool.c repos.h

On 01.08.2014 14:49, Stefan Fuhrmann wrote:
> * svn_config_enumerate2 accounts for more than 50%
> of the model filtering overhead. It's a mix of section lookup,
> iteration pool handling, hash iteration etc. end up being a
> massive overhead compared to the "is this name relevant"
> check that the actual callback wants to do.
> So, an array that could be iterated over directly would be nice.

Already done. :)

> * The parser context uses svn_stringbuf_t for parsed data.
> The parser interface should expose those - if only to provide
> the consumer with length info. It would even be o.k. for the
> consumer to modify / scrap the buffer contents if they feel
> the need.

Ah, good point; should be easy to make that change.

> * Try to do most of authz verification as part of the parsing.
> Again, iteration and lookup are expensive here.

Already done. :)

> * 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?

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).

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane_at_wandisco.com