summaryrefslogtreecommitdiff
path: root/docs/ACE-subsets.html
diff options
context:
space:
mode:
Diffstat (limited to 'docs/ACE-subsets.html')
-rw-r--r--docs/ACE-subsets.html195
1 files changed, 0 insertions, 195 deletions
diff --git a/docs/ACE-subsets.html b/docs/ACE-subsets.html
deleted file mode 100644
index 7c21fe002b2..00000000000
--- a/docs/ACE-subsets.html
+++ /dev/null
@@ -1,195 +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 is a worthy
-goal, the existing component definitions in
-<a href="../ace/ace.mpc">ace.mpc</a> are too tighly coupled.
-Therefore, even if ACE is compiled into multiple libraries,
-applications will 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>