From charlesreid1

No edit summary
Line 9: Line 9:
To perform a big O complexity analysis, we utilize random but seeded inputs that statistically sample the input space in a representative way. This ensures we aren't getting stuck measuring the runtime of a worst-case or best-case, and thus getting a skewed view of the algorithm.
To perform a big O complexity analysis, we utilize random but seeded inputs that statistically sample the input space in a representative way. This ensures we aren't getting stuck measuring the runtime of a worst-case or best-case, and thus getting a skewed view of the algorithm.


Corner cases and other kinds of timing tests, like adding and removing at a high, balanced rate and having a near-empty queue with high throughput.
Different kinds of timing tests, like adding and removing at a high, balanced rate and having a near-empty queue with high throughput.
 
Testing different operation times versus N, to plot on graphs and verify our code is correct.


===Memory usage===
===Memory usage===

Revision as of 01:06, 5 June 2017

Algorithmic analysis

While each data container is implemented differently, due to different tradeoffs between storage space and algorithmic complexity, it is useful to define a set of core tests for algorithmic analysis of data structures.

We begin with lists, which are arguably the simplest.

Big O complexity analysis

To perform a big O complexity analysis, we utilize random but seeded inputs that statistically sample the input space in a representative way. This ensures we aren't getting stuck measuring the runtime of a worst-case or best-case, and thus getting a skewed view of the algorithm.

Different kinds of timing tests, like adding and removing at a high, balanced rate and having a near-empty queue with high throughput.

Testing different operation times versus N, to plot on graphs and verify our code is correct.

Memory usage

No way to measure memory usage of objects in-memory, we are left on our own to performing memory profiling.


Flags