From af4e8c6f7b761b950ede3f66cb459dd053351abe Mon Sep 17 00:00:00 2001 From: Aria Shrimpton Date: Sat, 30 Mar 2024 01:13:26 +0000 Subject: some redrafting --- thesis/parts/introduction.tex | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) (limited to 'thesis/parts/introduction.tex') diff --git a/thesis/parts/introduction.tex b/thesis/parts/introduction.tex index aae5474..17830a9 100644 --- a/thesis/parts/introduction.tex +++ b/thesis/parts/introduction.tex @@ -3,16 +3,17 @@ %% **** Container types common in programs -A common requirement when programming is the need to keep a collection of data together, for example in a list. +Almost every program makes extensive use of container data structures -- structures which hold a collection of values. 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 a custom implementation to perform better. -Most programmers will simply use one or two collection types provided by their language. +However, implementing these collection types manually wastes time, and can be hard to do right for more complicated structures. +Most programmers will simply use one or two of the collection types provided by their language. +Some languages, such as Python, go a step further, providing built-in implementations of growable lists and associative maps, with special syntax for both. %% **** Large difference in performance -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}). +Unfortunately, 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}). +By largely ignoring the performance characteristics of their implementation, programmers may be missing out on large performance gains. %% *** 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. @@ -22,11 +23,17 @@ In our testing, we are able to accurately select the best performing containers %% **** Ease of adding new container types 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. +It is easy to adopt our system incrementally, and we integrate with existing tools to make 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. +The time it takes to select containers scales roughly linearly, even in complex cases, allowing our system to be used even on larger projects. %% **** Flexibility of selection -Our system is also able to suggest adaptive containers: containers which switch underlying implementation as they grow. +It is also able to suggest adaptive containers: containers which switch from one underlying implementation to another once they get past a cretain size. %% **** Overview of results -Whilst we saw reasonable suggestions in our test cases, we found the overhead of switching and of checking the current implementation to be more of a problem than expected, which future work could improve on. +Whilst we saw reasonable suggestions in our test cases, we found important performance concerns which future work could improve on. + +In chapter \ref{chap:background}, we give a more thorough description of the container selection problem, and examine previous work. We outline gaps in existing literature, and how we aim to contribute. + +Chapter \ref{chap:design} explains the design of our solution, and how it fulfills the aims set out in chapter \ref{chap:background}. Chapter \ref{chap:implementation} expands on this, describing the implementation work in detail and the challenges faced. + +We evaluate the effectiveness of our solution in chapter \ref{chap:results}, and identify several shortcomings that future work could improve upon. -- cgit v1.2.3