On Fri, Aug 1, 2014 at 1:23 PM, Branko Čibej <br...@wandisco.com> wrote:
> On 01.08.2014 13:07, Stefan Fuhrmann wrote: > > [...] > Ack, thanks for the explanation! > > I'm currently working on the improved parser and an in-memory > representation that should make generating the per-user filtered rules much > easier and faster. I'm not quite ready to commit right now, since I'm in > the middle of the second iteration of the in-memory struct design. :) > Excellent timing! I was about to give it a go over the weekend but there are plenty of other things left for me to look into. So far, I've done some scalability measurement and there is a series of upcoming patches. I'll summarize in a separate post. Things I've found during profiling that you might consider in your design: * 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. * 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. * Try to do most of authz verification as part of the parsing. Again, iteration and lookup are expensive here. * 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. > I'm doing this in new source files (will be authz_parse.c and > authz-test.c) so changing authz.c is fine for now. > I estimate to be done with my commits by Sunday and then see what happens. -- Stefan^2.
