[reSIProcate] "opt" builds

[Adam Roach]

David Thompson wrote:
> Thank you for your thoughts and I agree with you. In production we
> *shouldn't* ever get to the asserts in the first place. In my case, my
> program will run into it once every couple of days, and with a high volume
> of other concurrent calls, I was attempting to not have the entire program
> recycle due to the one anomaly (for accounting reasons).

Even without the assert()s, though, it's likely to dump core anyway. If 
the condition enforced by an assert() is false, you're probably going to 
end up dereferencing a null or stepping through a bad pointer in fairly 
short order.

> BTW, am I correct in assuming the OPT build is the best for final production
> build?
>   

I'm not certain that any thorough characterization of the resip stack 
with regards to compilation options has been undertaken recently enough 
to be relevant. If you're concerned with getting the most performance 
out of resip, you might want to spend some time tinkering around with 
various compile and link flags and profiling the resultant code. You 
also might consider purchasing Intel's Linux compiler, which is largely 
gcc compatible and produces somewhat faster code than gcc.

<shameless-plug>
Alternately, if performance is a primary concern, you might check with 
Estacado Systems, which has a performance-and-footprint optimized, 
commercially-supported version of the resip stack that runs about 30% 
faster than the publicly-available resip code. See 
<http://www.estacado.net/SIPBasis.html#foundation> for information.

(For full disclosure, I _am_ affiliated with Estacado Systems).
</shameless-plug>

/a