Add performance note after optimizations.

PERFORMANCE.md

@@ -27,3 +27,32 @@ change  |     98.96  %|    100.93  %|     96.13  %|    104.21  %|    103.86  %|
 Big improvements of about 6% in our test. This seems like a little,
 but 6% from the scheduler is a lot, as the 'main work' is the tasks
 itself, not the scheduler.
+
+### Commit 18b2d744 - Performance problems with higher thread counts
+
+After much tinkering we still have performance problems with higher
+thread counts in the FFT benchmark. Upward from 4/5 threads the
+performance gains start to saturate (before removing the top level
+locks we even saw a slight drop in performance).
+
+Currently the FFT benchmark shows the following results (average):
+
+<img src="media/18b2d744_fft_average.png" width="600"/>
+
+We want to positively note that the overall trend of 'performance drops'
+at the hyperthreading mark is not really bad anymore, it rather
+seems similar to EMBB now (with backoff + lockfree deque + top level
+reader-writers lock).
+
+This is discouraging after many tests. To see where the overhead lies
+we also implemented the unbalanced tree search benchmark,
+resulting in the following, suprisingly good, results (average):
+
+<img src="media/18b2d744_unbalanced_average.png" width="600"/>
+
+The main difference between the two benchmarks is, that the second
+one has more work and the work is relatively independent.
+Additionaly, the first one uses our high level API (parallel invoke),
+while the second one uses our low level API.
+It is worth investigating if either or high level API or the structure
+of the memory access in FFT are the problem.