[tao-users] Excessive memory allocation in TAO
Manjula Peiris
manjula.peris at gmail.com
Fri Jun 5 09:12:24 CDT 2015
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>
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
> > http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/tao-users
> >
>
> _______________________________________________
> tao-users mailing list
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.isis.vanderbilt.edu/cgi-bin/mailman/private/tao-users/attachments/20150605/f9b44a58/attachment-0001.html>
More information about the tao-users
mailing list