## Another look at algorithm time complexity

In my last post I wrote about various Fibonacci implementations in Elixir. I timed each implementation generating a list of the first N Fibonacci numbers, and compared the performance characteristics of each implementation. Based on what unwind said on Lobsters in response I decided to revisit Fibonacci implementations in Elixir. I’m going to update the implementatios I used in my last blog post so they use Erlang processes to store previously computed Fibonacci numbers. I’ll then benchmark each implementation against the Fibonacci implementation to see how much processes sped things up.

## Rewriting the Algorithms

I needed to have a process for each algorithm to store the computed Fibonacci numbers. I chose to create a single generic GenServer that I could spawn for each algorithm I was testing. Below is the implementation I settled on. It’s fairly straightforward. The only thing special about this GenServer code is that it allows the caller to specify the server they want to use. This is necessary because I will have multiple processes running different instances of this GenServer. One for each implementation I am testing. I need to have a different `FibStore`

server because each algorithm is different so I need to make sure I store and fetch Fibonacci numbers from the correct server.

```
defmodule FibStore do
use GenServer
def do_fib(name, number, fib_fun) do
case get(name, number) do
nil ->
result = fib_fun.(number)
put(name, number, result)
result
result ->
result
end
end
defp get(name, number) do
GenServer.call(name, {:get, number})
end
defp put(name, number, value) do
GenServer.call(name, {:put, number, value})
end
def maybe_start(name) do
case GenServer.start_link(__MODULE__, [], [name: name]) do
{:ok, _pid} ->
:ok
{:error, {:already_started, _pid}} ->
:ok
end
end
# GenServer callbacks
def init(_) do
{:ok, %{}}
end
def handle_call({:get, number}, _from, state) do
{:reply, Map.get(state, number), state}
end
def handle_call({:put, number, value}, _from, state) do
{:reply, :ok, Map.put(state, number, value)}
end
end
```

Next I needed to update the existing functions to use this new GenServer for fetching and storing values. The previous implementations had a `fib`

function that performed the actual computation. To avoid modifying a lot of code I added a new function named `do_fib`

that only calls the existing `fib`

function to do the computation if the Fibonacci number has not already been computed and stored in the GenServer instance. Below are the three new implementations:

### My Implementation

In my updated implementation so that the `fib`

clause for generating any number after the first two in the Fibonacci sequence invokes `FibStore.do_fib/3`

. This ensures it will reuse already an computed number if there is one. Otherwise `FibStore.do_fib/3`

will invoke `fib/1`

to compute and store the number.

```
defmodule MyFib do
def fibonacci(number) do
FibStore.maybe_start(__MODULE__)
Enum.reverse(FibStore.do_fib(__MODULE__, number, &fib/1))
end
def fib(0), do: [0]
def fib(1), do: [1|fib(0)]
def fib(number) when number > 1 do
[x, y|_] = all = FibStore.do_fib(__MODULE__, number-1, &fib/1)
[x + y|all]
end
end
```

### Rosetta Code

In much the same way I changed the Rosetta Code algorithm. It invokes `FibStore.do_fib/3`

when computing Fibonacci numbers so it uses pre-computed numbers if exist in the `FibStore`

process. Otherwise it invokes `fib/1`

to compute the Fibonacci number. Note that unlike my implementation this one must recompute everything when generating a new number in the sequence. For example, when generating the fifth number it would not be able to reuse the `2`

and the `3`

cached in the `FibStore`

process. I could not make it reuse pre-computed numbers without changing the way the `fib/3`

function works.

```
defmodule RosettaCodeFib do
def fibonacci(number) do
FibStore.maybe_start(__MODULE__)
Enum.map(0..number, fn(n) -> FibStore.do_fib(__MODULE__, n, &fib/1) end)
end
def fib(0), do: 0
def fib(1), do: 1
def fib(n), do: fib(0, 1, n-2)
def fib(_, prv, -1), do: prv
def fib(prvprv, prv, n) do
next = prv + prvprv
fib(prv, next, n-1)
end
end
```

### Popular Implementation/Dave Thomas

This implementation benefited the most from the `FibStore`

caching of pre-computed numbers. It remains similar to the original implementation, but now it invokes `FibStore.do_fib/3`

when computing numbers. Due to the recursive nature of the `fib/1`

function, calls are made to `FibStore.do_fib/3`

for every number that must be computed. This implementation is able to use the pre-computed numbers as a starting point when computing new numbers. Unlike the Rosetta Code implementation which cannot.

```
defmodule ThomasFib do
def fibonacci(number) do
FibStore.maybe_start(__MODULE__)
Enum.map(0..number, fn(n) -> do_fib(n, &fib/1) end)
end
def fib(0), do: 0
def fib(1), do: 1
def fib(n), do: do_fib(n-1, &fib/1) + do_fib(n-2, &fib/1)
defp do_fib(number, fun) do
FibStore.do_fib(__MODULE__, number, fun)
end
end
```

## Which function generates a list of Fibonacci numbers the fastest?

My bet was that my implementation would still perform better than the others, but I wasn’t sure which of the others would be the fastest. The Rosetta Code algorithm wasn’t able to leverage the `FibStore`

caching as much as others; but then again it was already a fairly fast algorithm.

## Benchmarking

I reused my benchmarking code from the first blog post. See the source file for the benchmarking code.

Since the new algorithms now maintain state their performance on the first run will differ from their performance on all subsequent runs. I decided I would run the benchmarks once to capture the performance on initial runs. Then I would run the benchmarks four more times to measure the performance on subsequent runs just as I did in my first blog post.

### Results

#### Initial Run

I ran the benchmark once to capture the performance when no state. Time is in microseconds.

Number | Rosetta Code | Dave Thomas' |
Mine |
---|---|---|---|

3 | 36 | 83 | 30 |

5 | 22 | 56 | 16 |

10 | 76 | 69 | 31 |

20 | 87 | 111 | 48 |

30 | 144 | 133 | 56 |

45 | 143 | 205 | 87 |

#### Four Subsequent Runs

After the first run I ran the benchmark again against each algorithm four times. The average run times are shown in the table below in microseconds.

Number | Rosetta Code | Dave Thomas' |
Mine |
---|---|---|---|

3 | 13 | 22 | 5 |

5 | 17 | 15 | 3 |

10 | 21 | 25 | 5 |

20 | 55 | 40 | 4 |

30 | 64 |
65 | 3 |

45 | 78 | 94 | 4 |

For comparison here are the average run times of the original algorithms:

List Size | Rosetta Code | Dave Thomas' | Mine |
---|---|---|---|

3 | 4 | 543 | 1 |

5 | 2 | 3 | 0 |

10 | 8 | 11 | 0 |

20 | 5 | 880 | 4 |

30 | 8 | 97500 | 1 |

45 | 17 | 131900822 | 2 |

## Conclusion

Looking at the data in these tables it’s clear the Dave Thomas algorithm benefited the most from the new process caching of computed numbers. This isn’t surprising due to the increasing number of recursive calls the original algorithm used when computing large numbers. It’s clear from the run times that the time complexity of the original algorithm was exponential. With the process caching in place the time complexity is no longer exponential. I didn’t take the time to figure it out, but I would guess the new Dave Thomas’ algorithm with process caching has linear time complexity.

The Rosetta Code algorithm doesn’t really benefit from the new process caching. The performance characteristics remain the same, and it runs nearly 5 times slower. My algorithm did not benefit from the process caching either. It ran about 4 times slower than the original algorithm. Even though processes are cheap on the Erlang VM, and local messages are fast it’s clear the overhead of caching the data in a separate process is taking a toll on these algorithms. Sending a message is cheap, but eventually the time it takes for the process to be scheduled after receiving a message adds up. When no data is cached these algorithms must send and receive at least 2 messages for every recursion needed to compute the final number. Even when the number has already been computed two messages are needed to fetch the number. The two original algorithms performed well by keep pre-computed numbers in process memory and reusing them when necessary, so this caching only reduces the arithmetic operations needed on subsequent calls. And even on subsequent calls the overhead of sending and receiving two messages is greater than the cost of computing the list of Fibonacci numbers all over again; at least for the first 45 Fibonacci numbers in the sequence.

When it comes to generating a list of the first N Fibonacci numbers my original algorithm still seems to be the fastest out of all the algorithms I’ve tested. My algorithm was designed from the ground up for specifically for generating a list of the first N Fibonacci numbers in the sequence so I think the take away here is that code written for a specific task may outperform code that is more general purpose.

## Resources

- Fibonacci Algorithms in Elixir Part 1
- https://lobste.rs/s/nz0vy6/fibonacci_algorithms_elixir#c_svloj7
- fib2.ex
- https://gist.github.com/pragdave/f8c7684b69d235269139bad0a2419273 *