Does Raise have measurable (negative) performance implications?

[404-]

While the new Raise DSL seems neat, I'm wondering what possible performance impact it might actually have. Given that the return type of raise is Nothing, I can only assume that under the hood the main mechanism relies on exceptions for flow control (please, correct me if I'm wrong). Unless something has changed, one of the JVM Commandments has always been: Thou shall not use Exceptions for simple flow control. Which brings me to my original concern: does the usage of raise come at the price of a measurable performance overhead?

To drive the point home, consider two possible implementations of a simple function responsible for making sure a number is positive:

fun positive(n: Int): Either<String, Int> =
  if (n > 0)
    n.right()
  else
    "[$n] is not a positive number".left()

fun positive(n: Int) = either<String, Int> {
  if (n > 0)
    n
  else
    raise("[$n] is not a positive number")
}

For the sake of the argument, imagine this function is a part of some application's critical path (e.g. a tight, performance-critical loop). Would the second implementation be expected to have a significantly negative impact on performance?

[nomisRev]

Hey @404-,

Thank you for your interest, and this is actually a great question!

It's not explicitly mentioned anywhere in the documentation, but perhaps it should! So Kotlin(X) Coroutines requires CancellationException to cancel a running coroutine, so for raise to properly work in the Kotlin ecosystem we're required to use CancellationException. (There are other implementation possible for Raise without using exceptions, but they don't cooperate nicely with other Coroutine code).

However there is no performance impact, since stacktrace creation is disabled. So the performance impact you're referring to comes from stacktrace creation, which occurs on construction of any subclass of Throwable. Stacktrace creation requires a JNI call to the native platform, and depending on how deep the stack is it'll become more expensive.

KotlinX Coroutines disables stacktrace creation for JobCancellationException for the same reasons as mentioned, and Arrow follows the exact same strategy and implementation as KotlinX Coroutines. Thus avoiding the performance impact.

For reference, Arrow, KotlinX Coroutines.

We replaced the DEBUG environment variable with the traced api which can be turned on ad-hoc at any place in the program.