[reSIProcate] the lazy-parser infrastructure, SipMessage, and pool-allocators

[Byron Campen <bcampen@xxxxxxxxxxxx>]

	I have spent a lot of time profiling the resip stack recently, and  
it seems that the amount of effort spent constructing/destructing the  
plethora of objects that make up the lazy-parser infrastructure (ie,  
HeaderFieldValueList, HeaderFieldValue, ParserContainerBase,  
ParserContainer, LazyParser, and ParserCategory) exceeds the effort  
we spend parsing by a wide margin. There are a few reasons for this:

	First, we are constructing stl vectors to hold single-value headers  
(To, From, CSeq, CallId, Max-Forwards, the RequestLine/StatusLine,  
Contents, Expires, etc), which make up most of the often-used  
headers. (I am referring to HeaderFieldValueList::mHeaders and  
ParserContainerBase::mParsers here.) Having a class that was  
specifically designed for this type of header could reduce overhead  
substantially.

	Second, when a SipMessage is copied, we allocate and memcpy for  
every (unparsed) header-field-value in the message, instead of  
leaning on the original message buffer and using some pointer-foo to  
calculate offsets. Changing this would mean slightly more logic in  
the application code (some pointer arithmetic), but malloc would not  
churn as badly, memcpying the entire buffer once would be  
substantially better than doing lots and lots of small memcpys of the  
individual HeaderFieldValues, and deleting one large buffer is also  
much, much better than deleting lots of small ones. We will probably  
also save memory with this approach, because malloc usually gives  
more memory than it is asked for.

	Third, classes like Uri, NameAddr, Via, and so forth have a  
ParserCategory and a LazyParser under the hood, whether they came  
from the wire or not. Whenever we create a Uri in code (as opposed to  
parsing it from the wire), it has to initialize a ParserCategory and  
a LazyParser, even though their capabilities almost certainly won't  
be used. However, changing this would be very difficult, and this  
does not appear to be hurting us too badly right now.

	In addition to these fixes, it may be helpful to pool-allocate  
SipMessages. This would require some modifications to SipMessage, but  
this should not be too hard. The downside of this approach is  
maintainability; if someone changes SipMessage by adding a member, we  
would have to ensure that the member is cleared before returning it  
to the pool.

        Does anyone have an opinion on this?

Best regards,
Byron Campen

Attachment: smime.p7s
Description: S/MIME cryptographic signature