[tao-users] Excessive memory allocation in TAO
Manjula Peiris
manjula.peris at gmail.com
Fri Jun 5 09:21:47 CDT 2015
Hi Johnny,
Sure, I will work on this.
Thanks,
Manjula.
On Fri, Jun 5, 2015 at 10:17 AM, Johnny Willemsen <jwillemsen at remedy.nl>
wrote:
> 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
>
>
--
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/4fb3d4fd/attachment-0001.html>
More information about the tao-users
mailing list