Optimize `runBlocking` and `EventLoop` implementations

• EventLoopBase implementation class should allocate both queue and delayed lazily, moreover, a queue shall not be allocated as long as there is at most one queued task (optimization that is similar to JobSupport)
• DispatchedContinuation shall extend QueuedTask, so that common case of EventLoop usage does not involve creation of objects at all.
• Consider providing a reusable version of EventLoop implementation, so that performance-sensitive code can create a single instance that is reused for multiple sequential invocations of runBlocking.

[elizarov]

No. Saving small object to ThreadLocal is usually counter-productive. Access to ThreadLocal is typically more expensive than allocation/collection of small objects. TheadLocal pooling is usually beneficial only for very large objects.

[qwwdfsad]

@tr8dr in general sendBlocking and offer have the same performance if send doesn’t suspend (aka there is enough buffer capacity), because internally it has the same (if (!offer()) { runBlocking {...}}) check.

For cases when channel capacity is saturated you should measure your performance on your specific workload because numbers out of thin air (“on my artificial benchmark sendBlocking is two times slower”) are mostly useless