Investigate: replace FastFuture with new future + ExecutionContext.callingThread

[helena]

See if FastFuture could be replaced by the new Future implementation combined with using ExecutionContext.callingThread shown here: https://github.com/scala/scala/pull/7784/files

thanks @viktorklang

[johanandren]

Note that we will be blocked on supporting Scala 2.11 (less) and 2.12 (more) for quite some time before we can actually migrate if it turns out on par. Good to investigate though.

[viktorklang]

@johanandren True—would be great to see what the diff looks like.

[viktorklang]

It has been renamed to ExecutionContext.parasitic -- Cheers, √

[jrudolph]

The main benefit of FastFuture is to avoid going through a dispatcher at all if the future has already been completed. In the best case if everything inlines perfectly we could get the same performance with the new execution context but that's the upper bound of what's possible. In any case, where inlining doesn't work for any reason or there's a true dynamic dispatch call-site because sometimes a future is already completed and sometimes not it cannot be faster.

Given the low complexity and maintenance overhead of FastFuture, I don't think it's worthwhile changing anything but I'd like to be proven wrong if someone cares :)

[viktorklang]

Getting stack safety is nice tho?

[jrudolph]

Getting stack safety is nice tho?

I think there's no recursion involved in FastFuture so not sure if there's anything that would be stack unsafe. It doesn't use the sameThreadExecutionContext, it just optimizes for the already completed case.

[viktorklang]

Ah, I'm thinking more if you mix Future and FastFuture.

[SethTisue]

I'm only mildly curious (it came up in a chat room), but perhaps I'm not the only one now wondering where this stands after scala/scala#7470 (Scala 2.13.0) and scala/scala#9270 (Scala 2.13.4)