| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
|
Changes
have been merged to main. Compile tested on Linux, mac os x and windows. Going
forward, any new code that needs to define an encoding function should use the
EncodeStream define instead of std::ostream so that the STL can be swapped out
with the new stream encoder. Encoding to cerr or cout needs to use
resipCerr and resipCout. The
alternate encoding mechanism is enabled by removing the RESIP_USE_STL_STREAMS
define in resipfaststreams.hxx. A
new test app is included in resip/stack/test called testSipMessageEncode.
The test encodes a sip message repeatedly and records the run time. Here are
my results on different hardware/os: Mac
Intel Core 2 Duo 2Ghz (OS X 10.5.4) 2GB RAM STL:
1sec No-STL: .7sec Speedup:
30% Windows
Intel Core 2 Duo 2.2Ghz (Vista 32-bit) 2GB RAM STL:
1.5sec No-STL: .3sec Speedup: 80% -justin From: Scott Godin
[mailto:slgodin@xxxxxxxxxxxx] Hi Justin, Thanks for kick starting this again. I think if your “fast-stream” modifications are
controlled via a define, and off by default (for now), then it’s a good
idea to move the branch into main. It will make it easier for people to
evaluate and play with, since it appears the branch approach didn’t
really work. ; ) Scott From:
resiprocate-devel-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Justin
Matthews 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
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||