[Date Prev][Date Next]
Re: IDL management in idl.c
Howard Chu wrote:
Have a look thru the archives of this mailing list. The current releases of
slapd spend over 50% of their CPU time in the malloc library. The gain from
being more careful about allocations here is tremendous.
I don't understand
your fear from an optimization point of view; there are no downsides to
the stack. From a security standpoint, we're dealing with items of bounded
size, so there is no risk of malicious overruns tweaking return addresses.
I thought the size of the input was unbounded. my mistake.
Correct me if I'm wrong. But since the stack's is fixed and slapd keeps
a large stack ( I think I was recommended 16megs ) then that equates to
16 megs/thread? Even if the queries serviced are very small. Would
that mean scaling issues for OpenLDAP? And we still have to resort to
the heap, for the overflow case.
Another issue this site brings up is that the stack is fixed at compile
Interesting note from the C-faq about alloca
Maybe a simple suballocator?
I was trying to get specific memory manager but I couldn't.
of course the risk of a deeply nested recursion running out of stack, but it
would take an extremely complex request to encounter that. Very likely the
limit on the maximum size of an input buffer would prevent such a request
from being accepted in the first place.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support
http://linuxquestions.org/ - Ask linux questions, give linux help.
http://splint.org/ - Write safe C code. splint source-code analyzer.