diff --git a/PERFORMANCE.md b/PERFORMANCE.md
index 2372c66..a57a66d 100644
--- a/PERFORMANCE.md
+++ b/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):
+
+
+
+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):
+
+
+
+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.
diff --git a/media/18b2d744_fft_average.png b/media/18b2d744_fft_average.png
new file mode 100644
index 0000000..f885ee8
Binary files /dev/null and b/media/18b2d744_fft_average.png differ
diff --git a/media/18b2d744_unbalanced_average.png b/media/18b2d744_unbalanced_average.png
new file mode 100644
index 0000000..bd2ac17
Binary files /dev/null and b/media/18b2d744_unbalanced_average.png differ