< Previous by Date Date Index Next by Date >
  Thread Index  

[reSIProcate] Fixing Memory Fragmentation and Increasing Performance (Part 1)


Hi guys,

I recently did a survey of the largest memory objects that resiprocate
has to offer using IDA on Windows (32-bit).

Here is a break down of the biggest offenders:

Biggest Offenders:
resip::EarlyDialogEvent: 0x700 bytes
resip::ProceedingDialogEvent: 0x700 bytes
resip::DialogEventInfo: 0x6F8 bytes
resip::StunMessage: 0x518 bytes
resip::SdpContents: 0x410 bytes (includes Session et al)
resip::SdpContents::Session: 0x350 bytes
resip::FdSet: 0x314 bytes
resip::RequestLine: 0x24C bytes
resip::NameAddr: 0x228 bytes
resip::Uri: 0x1CC bytes
resip::SdpContents::Session::Medium: 0x15C
resip::Log::Guard: 0x148 bytes
resip::MD5Stream 0x128 bytes
resip::Md5Buffer: 0xd4
resip::Via: 0xc8



It should be noted that Uri is really the worst of the worst in this
set.  On 32bit windows, it's 460 bytes without any data stored in it,
which is larger than the average sip message.  Given that there are a
bunch of Uris or NameAddrs in a given SIP Message, you can see how these
Sip Messages take up so much space in memory.

Byron and I have spoken about alleviating some of the situation by doing
a variety of changes that will increase performance, and reduce memory
consumption.


First and foremost, we believe it is in the best interest to remove some
of these unnecessary optimizations that take up excessive space and
provide no performance benefit (e.g. Aor caching).  Likewise 90+% of
URIs use a Scheme that is either sip: or sips.  This could be optimized
to take advantage of an enum for default values and an "Other" enum
value to handle other schemes.  Likewise, the most important fields in
any uri are User, Host, and Password.  We believe that the other fields
should be removed or allocated on the heap on a per usage basis to
remove the space requirements for them.

Additionally, we need to address the amount of memory consumption used
by Data, and how it should be handled and used going forward to improve
performance.  I will address that in part 2.

Dan