[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.


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 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.


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.