[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ACL check parameters



Hallvard B Furuseth wrote:
Howard Chu writes:
oprofile shows quite a bit more overhead in 2.4's ACL processing vs
2.3's. I'm thinking of streamlining things a bit, along these lines.
Any thoughts?

Only a few loose ones:

A brief look shows some deep indirection, which may be harder for
compilers to optimize due to possible aliasing among intervening writes.
Maybe you should help by unpacking some more common expressions into
local variables.

Profiling showed that the ACLCHECK branch didn't have any improvement over HEAD. Looks like it may not be worth the trouble.

Beyond that, seeing "ACL optimization" I think "bytecodes".  acl.c has
many if/switch statements just to find out what an acl expression is
doing.  A flat 'switch(*bytecode++)' implementation should help,
though I haven't looked closely and I'm not about to try anytime soon.

Of course, that points to a slapd.conf 'access' language which maps
more directly to the bytecodes, or compiler techniques like common
subexpression elimination and lazy evaluation... a mini Haskell
implementation in slapd, yay:-)

Yeesh...
--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/