2:33 p.m.
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?
This acl.c compiles, but a fair amount of slapd code needs to be altered to
use it. I guess if we commit and move forward on it it will have to be for 2.5.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:18 a.m.
Howard Chu wrote:
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?
This acl.c compiles, but a fair amount of slapd code needs to be altered to
use it. I guess if we commit and move forward on it it will have to be for 2.5.
It's all in the ACLCHECK branch now. Passes "make test" for me, haven't
done
any profiling on it yet. I suspect there's not much difference unless overlays
or other ACL plugins are in use.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12:25 p.m.
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.
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:-)
--
Hallvard
1:14 a.m.
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/
10:31 a.m.
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.
Are you going to drop this?
p.
2:54 p.m.
masarati(a)aero.polimi.it wrote:
> 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.
Are you going to drop this?
Yes, doesn't seem to offer any real benefit. If you can think of some other
reason to keep it, we can perhaps talk about how to make it viable.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:58 p.m.
masarati(a)aero.polimi.it wrote:
> Are you going to drop this?
Yes, doesn't seem to offer any real benefit. If you can think of some
other
reason to keep it, we can perhaps talk about how to make it viable.
Not necessarily a request to revitalize it; having a compact, neutral
interface for access control arguments would ease extending access control
in the future, if needed.
p.
4:23 p.m.
masarati(a)aero.polimi.it wrote:
> masarati(a)aero.polimi.it wrote:
>> Are you going to drop this?
>
> Yes, doesn't seem to offer any real benefit. If you can think of some
> other
> reason to keep it, we can perhaps talk about how to make it viable.
Not necessarily a request to revitalize it; having a compact, neutral
interface for access control arguments would ease extending access control
in the future, if needed.
True. I guess if there's no performance degradation (and it looks like not,
the performance impact was zero) then we can go ahead and adopt it.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5083
days inactive
5110
days old
7 comments
3 participants
participants (3)
-
Hallvard B Furuseth -
Howard Chu -
masarati＠aero.polimi.it