[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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.
agreed.
I don't understand
your fear from an optimization point of view; there are no downsides to
using
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
time... http://www.memorymanagement.org/faq.html#stack-only
Interesting note from the C-faq about alloca
http://www.eskimo.com/~scs/C-faq/q7.32.html
Maybe a simple suballocator?
http://www.memorymanagement.org/articles/alloc.html
I was trying to get specific memory manager but I couldn't.
--Kervin
There is
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
http://www.symas.com http://highlandsun.com/hyc
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.