# Smart Pointer Timings

In late January 2000, Mark Borgerding put forward a suggestion to boost for a new design of smart pointer whereby an intrusive doubly linked list is used to join together all instances of smart pointers sharing a given raw pointer. This allowed avoidance of the costly heap allocation of a reference count that occurred in the initial construction of the then current version of boost::shared_ptr. Of course, nothing is for free and the benefit here was gained at the expense of increased size and more costly copy operations. A debate ensued on the boost mailing list and the tests which this page describes were performed to provide a guide for current and future investigations into smart pointer implementation strategies.

Thanks are due to Dave Abrahams, Gavin Collings, Greg Colvin and Beman Dawes for test code and trial implementations, the final version of which can be found in .zip format here.

## Description

Two tests were run: the first aimed to obtain timings for two basic individual operations:

1. Initial construction from raw pointer.
2. An amortized copy operation consisting of half an assignment and half a copy construction - designed to reflect average usage.

The second attempted to gain more insight into normal usage by timing the fill and sort algorithms for vectors and lists filled with the various smart pointers.

Five smart pointer implementation strategies were tested:

1. Counted pointer using a heap allocated reference count, this is referred to as simple counted.
2. Counted pointer using a special purpose allocator for the reference count - special counted.
3. Counted pointer using an intrusive reference count - intrusive.
4. Linked pointer as described above - linked.
5. Cyclic pointer, a counted implementation using a std::deque for allocation with provision for weak pointers and garbage collection of cycles of pointers - cyclic.

on two compilers:

1. MSVC 6.0 service pack 3, using default release optimization mode (/O2 - optimized for speed, no inlining of functions defined outside a class body unless specified as inline).
2. gcc 2.95.2 using full optimization (-O3 -DNDEBUG).

Additionally, generated pointer sizes (taking into account struct alignment) were compared, as were generated code sizes for MSVC mainly by manual inspection of generated assembly code - a necessity due to function inlining.

All tests were run on a PII-200 running Windows NT version 4.0

##

## Operation Timing Test Results

The following graphs show the overall time in nanoseconds to acquire a pointer (default construction) perform n amortized copy operations on it and finally release it. The initial allocation time for the contained pointer is not included, although the time for it's deallocation is. The contained pointer pointed to a trivial class, but for the inclusion of an intrusive reference count for the benefit of the intrusive counted shared pointer. A dumb pointer (i.e. a smart pointer that simply acquires and releases its contained pointer with no extra overhead) and a raw pointer were also included for comparison.

Fitting straight lines to the above plots gives the following figures for initialization and amortized copy operation for the two compilers (times in nanoseconds, errors at two standard deviations) : -

#### MSVC

| initialization | copy operation
--- | --- | ---
simple counted | 3000 +/- 170 | 104 +/- 31
special counted | 1330 +/- 50 | 85 +/- 9
intrusive | 1000 +/- 20 | 71 +/- 3
linked | 970 +/- 60 | 136 +/- 10
cyclic | 1290 +/- 70 | 112 +/- 12
dumb | 1020 +/- 20 | 10 +/- 4
raw | 1038 +/- 30 | 10 +/- 5

####

#### GCC

| initialization | copy operation
--- | --- | ---
simple counted | 4620 +/- 150 | 301 +/- 28
special counted | 1990 +/- 40 | 264 +/- 7
intrusive | 1590 +/- 70 | 181 +/- 12
linked | 1470 +/- 140 | 345 +/- 26
cyclic | 2180 +/- 100 | 330 +/- 18
dumb | 1590 +/- 70 | 74 +/- 12
raw | 1430 +/- 60 | 27 +/- 11

Note that the above times include a certain amount of loop overhead etc. for each operation. An estimate of the pure smart pointer operation time 'overhead' can be obtained by subtracting the dumb or raw figure from the smart pointer time of interest.

### Detail

The test involved iterating a loop which creates raw pointers. These were then shared among a varying number (set size) of smart pointers. A range of set sizes was used and then a line fitted to get a linear relation with number of initializations and copy-operations. A spreadsheet was used for the line fit, and to produce the performance graphs above.

##

## Container Test Results

To gain some insight in to operation within real life programs, this test was devised. Smart pointers were used to fill standard containers which were then sorted.

In this case, the contained pointer pointed to a class which initializes a private data member to a random value in its default constructor. This value is used subsequently for the sort comparison test. The class also contains an intrusive reference count for the benefit of the intrusive counted pointer.

All times are in seconds for 300,000 contained pointers.

#### GCC

| vector | list
--- | --- | ---
| fill | sort | fill | sort
simple counted | 46.54 | 2.44 | 47.09 | 3.22
special counted | 14.02 | 2.83 | 7.28 | 3.21
intrusive | 12.15 | 1.91 | 7.99 | 3.08
linked | 12.46 | 2.32 | 8.14 | 3.27
cyclic | 22.60 | 3.19 | 1.63 | 3.18
raw | 11.81 | 0.24 | 27.51 | 0.77

#### MSVC

| vector | list
--- | --- | ---
| fill | sort | fill | sort
simple counted | 1.83 | 2.37 | 1.86 | 4.85
special counted | 1.04 | 2.35 | 1.38 | 4.58
intrusive | 1.04 | 1.84 | 1.16 | 4.29
linked | 1.08 | 2.00 | 1.21 | 4.33
cyclic | 1.38 | 2.84 | 1.47 | 4.73
raw | 0.67 | 0.28 | 1.24 | 1.81

## Code Size

The following code sizes were determined by inspection of generated code for MSVC only. Sizes are given in the form N / M / I where:

- N is the instruction count of the operation
- M is the size of the code in bytes
- I determines whether generated code was inlined or not I = inline, O = "outline"

| ptr() | ptr(p) | ptr(ptr) | op=() | ~ptr()
--- | --- | --- | --- | --- | ---
simple counted | 38/110/O | 38/110/O | 9/23/I | 22/57/I | 17/40/I
special counted | 50/141/O | 50/141/O | 9/23/I | 23/64/I | 13/38/I
intrusive | 1/2/I | 3/6/I | 3/6/I | 6/11/I | 6/11/I
linked | 5/19/I | 5/15/I | 10/30/I | 27/59/I | 14/38/I

During the code inspection, a couple of minor points were noticed: -

- Function inlining was critical to performance.
- For MSVC, at least, a "delete 0" caused execution of 11 assembly instructions, including a function call. So in cases where performance is at an absolute premium it can be worth inserting the extra manual test.

##

## Data Size

The following smart pointer sizes were obtained in bytes

| MSVC | GCC
--- | --- | ---
simple counted | 8 | 8
special counted | 8 | 12
intrusive | 4 | 4
linked | 12 | 12
cyclic | 8 | 8

##

## Summary

The timing results mainly speak for themselves: clearly an intrusive pointer outperforms all others and a simple heap based counted pointer has poor performance relative to other implementations. The selection of an optimal non-intrusive smart pointer implementation is more application dependent, however. Where small numbers of copies are expected, it is likely that the linked implementation will be favoured. Conversely, for larger numbers of copies a counted pointer with some type of special purpose allocator looks like a win. Other factors to bear in mind are: -

- Deterministic individual, as opposed to amortized, operation time. This weighs against any implementation depending on an allocator.
- Multithreaded synchronization. This weighs against an implementation which spreads its information as in the case of linked pointer.

Revised 19 August 2001

© Copyright Gavin Collings 2000. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright notice appears in all copies. This document is provided "as is" without express or implied warranty, and with no claim as to its suitability for any purpose.