It'll be speeded up further after we enhance hivemind to support microfork recovery. In the past, hivemind has always stayed 2 blocks behind the current block (i.e. 6 seconds in the past) because it didn't have a way to recover if it put data in the database that gets changed due to a microfork. We do have a plant to enhance the data that is placed into the database, so that hivemind can revert data from a microfork. Once that is possible, we can allow hivemind to directly report data from the head block of the blockchain, and this delay will no longer be necessary in condenser.
By the way, this is deployed in production now, just tested it and it works.
Thanks for the explanation, makes a lot of sense now understanding the concern with microforks.
What I wonder though, couldn't condenser itself bridge this delay with a cached estimate which then gets refined and solidified after 2-3 blocks of time? Basically having an instant response at the cost of a slight and momentary inaccuracy (payouts in $ are anyway in flux even if rshares don't change). I may miss problematic implications this can have but I consider it worth thinking in that direction since responsiveness is so critical for the user experience. Thanks!
Adding code to condenser to estimate it is possible, but if we're going to make hivemind faster soon, it's probably not worth it.
Sounds great.