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. br...@wandisco.com
