diff options
Diffstat (limited to 'ACE/docs/ACE-subsets.html')
| -rw-r--r-- | ACE/docs/ACE-subsets.html | 196 |
1 files changed, 0 insertions, 196 deletions
diff --git a/ACE/docs/ACE-subsets.html b/ACE/docs/ACE-subsets.html deleted file mode 100644 index ef2a1e0dcd1..00000000000 --- a/ACE/docs/ACE-subsets.html +++ /dev/null @@ -1,196 +0,0 @@ -<!-- $Id$ --> - -<html> - <head> - <title>ACE+TAO Subsetting</title> - <link rev=made href="mailto:ace-users@cs.wustl.edu"> - </head> - -<body text = "#000000" - link="#000fff" - vlink="#ff0f0f" - bgcolor="#ffffff"> - -<hr><p> -<H2>ACE+TAO Subsetting</H2> - -<p> -We are involved in ongoing activities to subset ACE+TAO to make them -more flexible and to reduce their memory footprint for embedded -systems. This document describes what we've done thus far, what we're -planning to do next, and how to leverage our efforts to minimize the -size of your ACE+TAO applications. </P> - -<hr> -<h3>Contents</h3> -<ul> - <li><a href="#pastwork">Past Work</a> - <li><a href="#futurework">Future Work</a> -</ul> - -<hr> -<h3><a name="pastwork">Past Work</a></h3> -<p> - -Previous ACE+TAO subsetting efforts were mainly concerned with -breaking up ACE into multiple libraries. Although this was a worthy -goal, the existing component definitions in <a -href="../ace/ace.mpc">ace.mpc</a> are too tightly coupled. Even if -ACE was compiled into multiple libraries, therefore, applications -would still have to link almost every one of them.</p> - -<p> -Potentially more satisfying results can be obtained through the use of -namespaces, e.g., ACE_OS, and/or breaking up large cpp's into smaller -ones to decrease the size of object files, and statically linking them -into the application.</p> - -<p> -In fact, this technique was applied systematically to ACE_OS in 2003, -and resulted in a <a -href="http://www.dre.vanderbilt.edu/Stats/footprint.shtml">10-15% -decrease in overall footprint</a> for statically linked applications. -Interestingly, these techniques also helped reduce <a -href="http://www.dre.vanderbilt.edu/~isisbuilds/auto_compile_logs/CP_Metrics/metrics/">compilation -times by ~50%</a>.</p> - -<p> -Another very powerful technique for reducing the size of shared -libries is <a href="../apps/soreduce/README">The Shared Library -Reduction (<CODE>soreduce</CODE>) tool</a>. <code>soreduce</code> -also benifits from the techniques listed above and should give -results comparable to static linking. In fact, when deploying multiple -applications, use of shared libraries with <code>soreduce</code> will -result in smaller overall footprint than static linking.</p> - -<hr> -<h3><a name="futurework">Future Work</a></h3> -<p> - -Depending on funding and contributions from the ACE community, future -work on subsetting in ACE can be divided into two thrusts: <P> - -<UL> - -<LI> <B>Code refactoring</B>, which helps to reduce the coupling -between applications and ACE C++ wrappers and frameworks. The amount -of coupling that's in ACE currently yields larger compiled size for -executable applications, increased link times, and indirect dependency -on a large amounts of code that may not be needed for many embedded -applications. <P> - -<LI> <B>Functionality Refactoring</B>, which enables application -developers to choose lightweight reusable classes and frameworks, -rather than monolithic and heavyweight implementations, to decrease -compilation times, link times, and compiled memory footprint of -embedded applications. <P> - -</UL> - -Our ideas for performing each of these thrusts is described in detail -below. - -<h4>ACE Code Refactoring</H4> - -ACE is currently designed in such a way that application developers -must link many classes and methods of ACE with their application, even -if they use a small number of classes and functions in their -application. As a result, static memory resource utilization is -unnecessarily high for common use cases. This section describes -techniques to address the existing code structuring complexities in -ACE, which were originally driven by the poor quality of C++ tools -that were available in the 1990's. For example, early C++ compilers -in the embedded domain lacked support for namespaces, which forced -developers to write classes that had a number of utility functions -useful for network programming. Now that modern C++ compilers have -better support for standard C++, we propose the following -optimizations to ACE: <P> - -<UL> - -<LI> We will identify ACE classes and utility functions that serve a - common goal, and move them into a namespace of their own. Since C++ - allows a single namespace to be reopened in multiple translation - units, we plan to split the operations into multiple C++ source - files, giving the linker a chance to choose a smaller sized object - files while creating an executable. <P> - -<LI> Currently, ACE inlines many of its methods, which tradesoff run-time - performance for larger footprint. We propose to examine the contents - of inlined files in ACE, and evaluate whether inlining is required in - every instance. ACE aggressively inlined functions to get better - performance from the tool chains, but this has lead to increased code - coupling within ACE, as well as increased coupling between - applications that use ACE. We will evaluate the tradeoffs associated - with inlining and performance of certain functions and selectively - inline those methods. These optimizations are described further in - <A -HREF="http://www.amazon.com/exec/obidos/tg/detail/-/0201379503/104-7731669-1857527?v=glance">Efficient -C++: Performance Programming Techniques</A> by Dov Bulka and - David Mayhew. -</UL> - -We expect that we will be able to reduce footprint by ~25-30% for ACE -applications, and a ~15-20% reduction in compile and link time of -applications. <P> - -<H4>Functionality Refactoring</H4> - - This section proposes to address additional compile-time and memory -footprint problems that can be solved by functionality refactoring. -During the past decade, ACE has been designed and built based on many -unique requirements from users around the globe. Though this input -enhanced the flexibility of ACE and increased the visibility of ACE, -it also led to functionality "clumping," i.e., many classes in ACE -have functionality associated with them that are not required for many -applications. For example, the ACE_Svc_Handler serves as an event -handler for the ACE Reactor framework, serves as a handler to -implement the thread-per-connection strategies, and can be dynamically -loaded from shared libraries using the ACE Service Configurator -framework, which in turn depends on the ACE Reactor framework. Though -all these dependencies and functionalities are required for some -applications, they yield excessive coupling and overhead for -applications (such as clients) that only want to use the ACE -Acceptor/Connector framework to connect and send messages to remote -servers. <P> - - To address the issues of tight-coupling outlined above, we propose -to refactor the code and functionality of the existing ACE frameworks -and wrapper classes to offer finer-grained components that can be -selectively included by embedded applications. Our initial efforts -would focus on the following key ACE frameworks: -<UL> -<LI> Logging -<LI> Service Configurator -<LI> Object Manager -<LI> Reactor -<LI> Framework Component -<LI> Thread Manager -<LI> Proactor -</UL> - -We propose to apply the techniques we have mentioned above. As a -result, we expect that we will be able to reduce footprint by another -~20-25% for certain classes of ACE applications, and a ~15-20% -reduction in compile- and link-time of applications. <P> - - Collectively, the optimizations we propose above will greatly -reduce the memory footprint and speedup the compilation and link time -for ACE-based applications. <P> - -<p> Anyone interested in contributing time or funding to these efforts -should please contact <a -href="mailto:d.schmidt@vanderbilt.edu">d.schmidt@vanderbilt.edu</a>. -If you have questions about ACE and/or ACE subsetting and footprint -reduction please post these questions to the <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">ACE mailing -list</A>.</p> - -<P><HR><P> -Back to the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A> -home page.<BR> -Back to <A HREF="index.html">ACE Documentation Home</A>. - -<!--#include virtual="/~schmidt/cgi-sig.html" --> -</BODY> -</HTML> |