[reSIProcate] STL stream performance enhancement for SipMessageencoding

[Justin Matthews]

Agreed.  

 

Thanks.

 

-justin

 

From: Scott Godin [mailto:slgodin at icescape.com] 
Sent: Thursday, May 29, 2008 9:06 AM
To: Justin Matthews; resiprocate-devel at list.resiprocate.org
Subject: RE: [reSIProcate] STL stream performance enhancement for
SipMessageencoding

 

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 at resiprocate.org
[mailto:resiprocate-devel-bounces at resiprocate.org] On Behalf Of Justin
Matthews
Sent: Thursday, May 29, 2008 8:52 AM
To: resiprocate-devel at list.resiprocate.org
Subject: Re: [reSIProcate] STL stream performance enhancement for
SipMessageencoding

 

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:] 
Sent: Wednesday, December 06, 2006 2:47 PM
To: 'resiprocate-devel at list.resiprocate.org'
Subject: STL stream performance enhancement for SipMessage encoding

 

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

 


Test Scenario 1

	
	

 

 

 

 

 

 

	

Description:

Running testSipMsgEncode.cxx in
branches/b-jmatthewsr-streamperf/resip/stack/test

 

 

	

 

 

	

 

arguments: -r 500000

 

 

	

 

 

 

 

 

 

	

Test platform

STL Encode (sec)

NO STL Encode (sec)

Factor

 

 

	

 

 

 

 

 

 

	

Win32 Pentium D 2.8Ghz

8.9

1.7

5.24

 

 

	

 

 

 

 

 

 

	

Win32 Pentium 4 3.0Ghz

9.8

1.5

6.53

 

 

	

 

 

 

 

 

 

	

Linux-nodebug Fedora 5 under VMware on Pentium D 2.8Ghz

6.4

5.9

1.08

 

 

	

 

 

 

 

 

 

	

Test Scenario 2

	
	

 

 

 

 

 

 

	

Description:

B2BUA, test setup running 120 lines (simulator)

 

 

	

 

 

	

Test platform

STL Average CPU %

NO STL Average CPU %

Avg CPU % Change

Max CPU STL

Max CPU NO STL

	

 

 

 

 

 

 

	

Win32-Release Pentium D 2.8Ghz @ approx 1.5 calls/sec, 500 total calls

3.43

2.34

31.78%

44

30

	

 

 

 

 

 

 

	

Win32-Release Pentium 4 3.0Ghz @ approx .63 calls/sec, 231 total calls

3.25

1.93

40.62%

30

18

	

Test platform

STL Encode (sec)

NO STL Encode (sec)

Factor

 

	

 

 

 

 

 

	

Win32 Pentium D 2.8Ghz

8.9

1.7

5.24

 

	

 

 

 

 

 

	

Win32 Pentium 4 3.0Ghz

9.8

1.5

6.53

 

	

 

 

 

 

 

	

Linux-nodebug Fedora 5 under VMware on Pentium D 2.8Ghz

6.4

5.9

1.08

 

	
									
 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20080529/b1d76a87/attachment.htm>