Re: [reSIProcate] "opt" builds
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