Kotlin Arrow EffectScope.shift()抛异常？性能优化疑问

问题本质 #

你注意到的矛盾确实存在：Arrow的函数式错误处理文档强调要避免抛出异常以减少性能损耗（参考《The hidden performance costs of instantiating Throwables》），但shift()（以及依赖它的bind()）底层却通过抛出异常来实现控制流切换，甚至处理Option.None、Either.Left时也会创建Throwable实例。

内部优化措施 #

Arrow针对这个问题做了不少针对性优化：

• 复用预定义异常实例：对于常见的失败场景（比如Either.Left转换、Option.None解包），库内部维护了共享的Throwable实例，不会每次触发失败都新建对象，直接减少实例化的开销。
• 精简栈轨迹收集：默认情况下，Arrow用于控制流的异常不会收集完整的栈轨迹——栈轨迹是Throwable实例化开销的主要来源之一。通过禁用这部分收集，能大幅降低创建Throwable的性能成本。
• 编译期内联与插件优化：借助Kotlin的内联函数特性，bind()这类调用会在编译时展开，减少额外的函数调用层级；同时Arrow的编译插件会对Effect相关逻辑进行重写，进一步优化异常控制流的执行路径。

实际性能影响 #

• 日常场景可忽略：除非你在写极端高频的循环（比如每秒百万级调用的核心计算逻辑），否则Throwable实例化的开销在整体性能中占比极低。业务代码的性能瓶颈通常集中在IO、数据库查询、复杂算法这些环节，而非这类底层控制流的开销。
• 优于传统异常滥用：Arrow的异常使用是库内部的控制流实现，不会像业务代码中随意抛异常那样产生额外的上下文开销，经过优化后的性能表现远好于无节制的异常抛出。

结论 #

Arrow已经通过多种手段将Throwable实例化的性能损耗降到了最低，绝大多数实际业务场景下完全不需要担心这个问题。如果确实处于极端性能敏感的场景，可以考虑自定义Effect类型来规避异常，但这属于小众需求，官方的优化方案已经覆盖了绝大多数情况。

内容的提问来源于stack exchange，提问作者rascio