1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
%% *** Introduce problem
%% **** 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.
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.
%% **** 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}).
%% *** 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.
In our testing, we are able to accurately select the best performing containers for a program in significantly less time than brute force.
%% *** Overview of aims & approach
%% **** 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.
%% **** 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
Our system is also able to suggest adaptive containers: containers which switch underlying implementation as they grow.
%% **** 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.
|
