[tao-users] Excessive memory allocation in TAO

[James H. Hill]

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,000				2.275431			2.25299			0.98%
20,000				4.589058			4.491926			2.16%
30,000				6.972080			6.825455			2.10%
40,000				9.51474			9.419871			0.99%
50,000				11.487203		11.291216 		1.70%
100,000				22.917998		22.587449		1.44%
200,000				52.195151		45.445869		12.93%
300,000				68.968680		63.624066		7.74%
400,000				91.914805		85.586583		6.88%
500,000				115.174436		106.963704		7.12%

We would like to know your thoughts on this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.isis.vanderbilt.edu/cgi-bin/mailman/private/tao-users/attachments/20150604/b0a818ae/attachment.html>