Thank you @kyri-petrou! Yes, please feel free to submit library upgrades and even new benchmarks, especially if they show areas that Kyo doesn't perform well!

We have similar benchmarks to the one you used for the optimization but with some important differences that can influence performance. I've prepared a PR with a port of ZIO's benchmark: #304.

What is the FiberRoots config? Could we enable it for all ZIO benchmarks?

I was trying to check how ZIO performs with Kyo's scheduler but I'm having trouble to configure it. My failed attempt so far:

        @Benchmark
        def forkZio(): T = zio.Unsafe.unsafe(implicit u =>
            val exec = new ZioKyoExecutor
            zio.Runtime.unsafe.fromLayer(zio.Runtime.setExecutor(exec) ++ zio.Runtime.setBlockingExecutor(exec))
                .run(zio.ZIO.yieldNow.flatMap(_ => zioBench())).getOrThrow()
        )

I also wanted to remove this configuration from the hot path of the benchmark execution and put the runtime in a pre-initialized val to reduce overhead but the requirement of an Unsafe evidence doesn't seem to allow that.

You can use Unsafe.unsafe{ } directly to remove the unsafe requirement.

@fwbrasil I think the best way to

I also wanted to remove this configuration from the hot path of the benchmark execution and put the runtime in a pre-initialized val to reduce overhead but the requirement of an Unsafe evidence doesn't seem to allow that.

I think the best way to do this would be something along these lines:

import kyo.scheduler.Scheduler as KyoScheduler
import zio.*

object ZioRunner {
  private given Unsafe = Unsafe.unsafe(identity)

  private val kExecutorLayer = Runtime.setExecutor(Executor.fromJavaExecutor(KyoScheduler.get.asExecutor))
  private val rt             = Runtime.unsafe.fromLayer(kExecutorLayer).unsafe

  def run[A](f: ZIO[Any, Throwable, A]) = rt.run(f).getOrThrowFiberFailure()
}

Note that in Scala 3 you could also do this (notice it's unsafely instead of unsafe, which uses a context function)

def run[A](f: ZIO[Any, Throwable, A]) = Unsafe.unsafely(rt.run(f).getOrThrowFiberFailure())

What is the FiberRoots config? Could we enable it for all ZIO benchmarks?

@fwbrasil The FiberRoots is a runtime flag, and it's enabled by default in the ZIO runtime. It adds an considerable overhead to fork-join performance, but it's required for tracking fibers that have been forked in the global scope.

The tracking of fibers is mostly necessary for being able to interrupt them safely and await for their completion when the application exits

@kyri-petrou Thanks for the tips! I used a similar approach to set the executor in #306. There's a performance regression I still have to investigate.

About FiberRoots, it seems a good optimization opportunity! Weak references have some GC impact because objects survive an extra GC cycle and a global collection pointing to fibers can limit scalability. Loom for example doesn't enable thread dumps for virtual threads by default.

For safe closing of resources, maybe you could track the resources themselves instead of all fibers since it's typically a much smaller set? For fiber dumps, the scheduler itself should already have a reference to all active fibers but that would have a compromise of not reporting suspended fibers.

@fwbrasil thanks for the recommendations! I agree that FiberRoots is something that could potentially be redesigned or potentially be turned off by default. Also, I'm not even entirely sure whether having resources forked in the global scope is actually even a use-case; perhaps it's not. Personally, for projects at $WORK I have FiberRoots disabled 😅.

By the way zio v2.1.0-RC4 was just released where I added a very convenient method for disabling runtime flags.
You can try disabling FiberRoots in your benchmarks by creating a new Runtime as:

Unsafe.unsafely {
  Runtime.unsafe.fromLayer(Runtime.disableFlags(RuntimeFlag.FiberRoots)).unsafe
}