[tao-users] Excessive memory allocation in TAO

[Johnny Willemsen]

Hi,

Thanks for the post, I haven't checked all code, but as far as I
remember it is not guaranteed that target is an empty sequence, so with
your patch when there is data in target that is not cleared. In case
new_length is 0 shouldn't then the length of target be set to 0?

Best regards,

Johnny

On 06/04/2015 09:24 PM, James H. Hill wrote:
> Hi all,
> 
> Sorry if this is a repost, but I was not part of the mailing list when I
> sent the original email.
> 
> My student Manjula, who is CCed on this email, is working on an analysis
> tool built atop of the Pin dynamic binary instrumentation (DBI)
> framework for automatically identifying the Excessive Memory Allocation
> software performance anti-pattern. The analysis tool is able to identify
> the exact function(s) that are the source of excessive memory allocations. 
> 
> We have applied analysis tool to several open-source projects, including
> TAO. Please see his findings below for identifying excessive memory
> allocation in TAO, and how the problem is resolved.
> 
> He welcomes all feedback.
> 
> Thanks,
> 
> James
> 
> 
> Unnecessary/Excessive dynamic memory allocation in Unbound_Sequence_CDR_T.h
> ----------------------------------------------------------------------------------------------------------------------
> 
> TAO seems to be doing a zero size memory allocation in the following
> code which can be found in *Unbound_Sequence_CDR_T.h.*
> *
> *
> 
> template <typename stream, typename value_t>
> bool demarshal_sequence(stream & strm, TAO::unbounded_value_sequence
> <value_t> & target) {
> typedef TAO::unbounded_value_sequence <value_t> sequence;
> ::CORBA::ULong new_length = 0;
> if (!(strm >> new_length)) {
> return false;
> }
> if (new_length > strm.length()) {
> return false;
> }
> 
> // The code we aded
> 
> if (new_length == 0)
> return true;
> 
> // End of the code.
> 
> sequence tmp(new_length); // This is where the actual allocations happens
> tmp.length(new_length);
> typename sequence::value_type * buffer = tmp.get_buffer();
> for(CORBA::ULong i = 0; i < new_length; ++i) {
> if (!(strm >> buffer[i])) {
> return false;
> }
> }
> tmp.swap(target);
> return true;
> }
> 
> 
> As shown in the above code TAO will continue on creating a sequence
> object (using sequence tmp(new_length)), even when new_length is zero.
> This code segment is called from the following statement in
> the *TAO_GIOP_Message_Generator_Parser_12::parse_request_header
> ()* function.
> 
> *input >> req_service_info (line 281 in my revision)*
> 
> where, input is of type *TAO_InputCDR* and req_service_info is of
> type *IOP::ServiceContextList*.
> 
> Multiple zero size calls to new[] is possible when the same client sends
> multiple requests to the same service. For the first request the value
> for the new_length variable is 1. But when that same client sends
> subsequent requests the new_length variable is 0. Now the statement
> "*sequence time(new_length)*" allocates a list of buffers using new[]
> operator for each request. However it needs this only for the first
> request, allocating a buffer list using new[] of zero size is
> unnecessary for subsequent requests. If a client is sending 1000
> requests to the same service 999 of calls to new[] is unnecessary.Simple
> fix is, returning immediately when the new_length is 0. The two lines of
> code I have added is colored in blue.
> 
> Following are some performance results for the echo service for multiple
> requests using the same client in Windows 7 as the platform. There is a
> 5-10% performance gain for larger number of requests. This is the time
> it takes to complete n number requests measured at the client side. The
> performance gain may depend on the platform you are testing. However the
> important thing is this zero size dynamic memory allocations seems to be
> unnecessary and it can be avoided simply by returning if the new_length
> value is 0.
> 
> Number of requests     Before the fix            After the fix        
> Percentage Diff
> (sec.usec)(sec.usec)
> 
> 10,0002.2754312.252990.98%
> 20,0004.5890584.4919262.16%
> 30,0006.9720806.8254552.10%
> 40,0009.514749.4198710.99%
> 50,00011.48720311.291216 1.70%
> 100,00022.91799822.5874491.44%
> 200,00052.19515145.44586912.93%
> 300,00068.96868063.6240667.74%
> 400,00091.91480585.5865836.88%
> 500,000115.174436106.9637047.12%
> 
> We would like to know your thoughts on this.
> 
> 
> _______________________________________________
> tao-users mailing list
> tao-users at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/tao-users
>