[tao-users] Excessive memory allocation in TAO

Johnny Willemsen jwillemsen at remedy.nl
Fri Jun 5 09:17:51 CDT 2015


Hi,

Any performance improvement is very welcome (at least when it doesn't
break normal functionality).

Can you work on a patch that works in all cases (try to run our unit
tests, especially tests/sequence_unit_tests) and when you have something
that works create a pull request on https://github.com/DOCGroup/ATCD/
for review and integration.

Best regards and thanks for looking at this

Johnny Willemsen
Remedy IT

On 06/05/2015 04:12 PM, Manjula Peiris wrote:
> Hi Johnny,
> 
> This may not be the correct fix as my knowledge on TAO is very limited.
> My aim with this fix was to prevent the unnecessary dynamic memory
> allocation, when the new_length is zero and validate the technique of my
> tool. A proper fix may be to do this check at a lower level, may be
> in Unbounded_Value_Allocation_Traits_T.h. That way we can still swap the
> pointers without the unnecessary allocation when the new_length is zero.
> 
> Thanks,
> Manjula.
> 
> On Fri, Jun 5, 2015 at 2:21 AM, Johnny Willemsen <jwillemsen at remedy.nl
> <mailto:jwillemsen at remedy.nl>> wrote:
> 
>     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
>     <mailto:tao-users at list.isis.vanderbilt.edu>
>     > http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/tao-users
>     >
> 
>     _______________________________________________
>     tao-users mailing list
>     tao-users at list.isis.vanderbilt.edu
>     <mailto:tao-users at list.isis.vanderbilt.edu>
>     http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/tao-users
> 
> 
> 
> 
> -- 
> Manjula Peiris
> Research Assistant / PhD Student
> Department of Computer & Information Science
> IUPUI



More information about the tao-users mailing list