diff options
Diffstat (limited to 'thesis/parts/introduction.tex')
| -rw-r--r-- | thesis/parts/introduction.tex | 24 |
1 files changed, 13 insertions, 11 deletions
diff --git a/thesis/parts/introduction.tex b/thesis/parts/introduction.tex index 452a6d8..6886f35 100644 --- a/thesis/parts/introduction.tex +++ b/thesis/parts/introduction.tex @@ -3,28 +3,30 @@ %% **** Container types common in programs -The vast majority of programs will make extensive use of collection data types --- types intended to hold multiple instances of other types. -This allows programmers to use things like growable lists, sets, or trees without worrying about implementing them themselves. +A common requirement when programming is the need to keep a collection of data together, for example in a list. +Often, programmers will have some requirements they want to impose on this collection, such as not storing duplicate elements, or storing the items in sorted order. %% **** Functionally identical implementations +However, implementing these collection types manually is usually a waste of time, as is fine-tuning their implementation to perform better. +Most programmers will simply use one or two collection types provided by their language. -However, this still leaves the problem of selecting the ``best'' underlying implementation. -Most programmers will simply stick with the same one every time, with some languages like Python even building in a single implementation for everyone. %% **** Large difference in performance -While this is simplest, it can have a drastic effect on performance in many cases (\cite{l_liu_perflint_2009}, \cite{jung_brainy_2011}). +Often, this is not the best choice. +The underlying implementation of container types which function the same can have a drastic effect on performance (\cite{l_liu_perflint_2009}, \cite{jung_brainy_2011}). %% *** Motivate w/ effectiveness claims +We propose a system, Candelabra, for the automatic selection of container implementations, based on both user-specified requirements and inferred requirements for performance. %% *** Overview of aims & approach - -We propose a system for the automatic selection of container implementations, based on both user-specified requirements and inferred requirements for performance. -%% **** Scalability to larger projects -%% **** Ease of integration into existing projects %% **** Ease of adding new container types -Our system is built to be scalable, both in the sense that it can be applied to large projects, and that new container types can be added with ease. +We have designed our system with flexibility in mind --- adding new container implementations requires little effort. +%% **** Ease of integration into existing projects +It is easy to adopt our system incrementally, and we integrate with existing tools to making doing so easy. +%% **** Scalability to larger projects +The time it takes to select containers scales roughly linearly, even in complex cases, allowing our tool to be used even on larger projects. %% **** Flexibility of selection -We are also able to detect some cases where the optimal container type varies at runtime, and supply containers which start off as one implementation, and move to another when it is more optimal to do so. +Our system is also able to suggest adaptive containers --- containers which switch underlying implementation as they grow. %% *** Overview of results \todo{Overview of results} |