< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index | Next in Thread > |
A
while back I posted on how the performance of resip could be improved by
replacing the STL streams library on Windows and Linux/others. I believe that
this is still a worthwhile enhancement to the project and would like to propose
a first step in moving toward a faster encoding mechanism in resip. Step
1 would be to replace all occurrences of std::ostream that relate to encoding
with a typedef (used as a simple placeholder for now). This would later
be defined as a custom encoder. Example: typedef std::ostream
resip::EncodeStream. Any
comments/objections to this change? Thanks, -justin From: Justin Matthews
[mailto:] After
integrating the resip stack into our application, initial profiling showed that
we could improve performance significantly by replacing the STL streams classes
that are used for encoding SipMessage objects. The
code is checked in under branches/b-jmatthewsr-streamperf. Note that at
this time only the default settings for ./configure should be used and repro is
currently excluded from the build. The
data below shows (on win32) a 30-40% overall CPU reduction when running our
application with the STL alternative and a 5-6x factor improvement running the
stand alone encoder test. Note that although the CPU usage is relatively
low, under heavier call load the significance of the STL alternative becomes greater. I
would really appreciate some feedback from running the stand-alone test apps
(STL vs alternative) on additional windows hardware as well as true Linux (not
running under virtual machine)/unix/osx machines. I have binaries for win32 and
for linux (fedora 5) that I can send on request. To build the test app in
the branch define/undefine RESIP_USE_STL_STREAMS in
rutil/resipfaststreams.h. The test app is under
resip/stack/test/testSipMsgEncode.cxx. Thanks, -Justin Running
the test app with args: test.exe -r 500000
|