Martin Leitner-Ankerl

code review ACK fab46cc

re-ACK b1318dcc56a0181783ee7ddbd388ae878a0efc52

Hi, I wonder how you measured the runtime, is there a benchmark? Another optimization that might be worth it, it is to replace the `std::multimap forward` with an `std::unordered_map forward`.

I didn't think this through yet, but this might be an alternative way to achieve the same thing: Instead of the double linked list, split the `cacheCoins` map up into...

> @martinus something similar was mentioned in [#15265 (comment)](https://github.com/bitcoin/bitcoin/pull/15265#issuecomment-457720636). However, with your approach every access would require 4 lookups. Ha, of course; I didn't think about that at all.

As mentioned `std::cout` is supposed to be threadsafe: https://eel.is/c++draft/iostream.objects#overview-7 The problem is, it seems that io manipulators are *not* threadsafe: the stream members are not atomic, and there are no...

Someone (not me) created a bug for exactly this issue, with a nice short reproducer: https://bugs.llvm.org/show_bug.cgi?id=52509 In C++20 there will be `std::osyncstream`: https://en.cppreference.com/w/cpp/io/basic_osyncstream So I think it would be nice...

Thanks @jonatack , I've rebased 6b0537c -> 6a9c6ea. Fixed Makefile & include conflict, and added a `reserve()` in a unit test to fix a clang-tidy warning.

I updated my PR by removing the changes that I did in initializer-lists. These were not necessary, evaluation order in these is well defined.

> I am wondering if this is worth it at this point, since we only fuzz with llvm based compilers. I don't know how stable the ordering is for llvm....