模式匹配开销?

时间:2017-12-17 21:59:06

标签: scala apache-spark pattern-matching

我是Scala和Spark的新手,我正在研究算法的实现。我想知道scala模式匹配的使用是否方便以提高代码可读性,或者它是否在执行期间实际引入了显着的开销。我经常需要在地图函数中管理复杂对象/嵌套元组,所以我问你通常的方法是什么。通常在我的比赛中没有真正的比较,它就像是

COLLECTION.map{ case (A, (_,(C,_))) => do something with A and C) }

而不是

COLLECTION.map(pair => do something with pair._1 and pair._2._2._1)

非常感谢。

2 个答案:

答案 0 :(得分:1)

编译器在第一个代码示例中调用模式匹配的unapply函数可能比第二个示例更昂贵,后者不需要对值或类型进行内省或运行时测试。但是,第二个示例将失败,除非集合中的所有元素都是预期类型,并且您没有向编译器指出预期的类型。

第一个示例中的模式匹配是否会产生显着的开销取决于它相对于程序其余部分中的计算调用的频率。

答案 1 :(得分:1)

匹配的开销很小。元组匹配将参数直接提升为元组,不使用unapply处理元组模式。

中的f
class Foo {
  val f: ((Double, Int)) => Double = { case (d, i) => d + i }
}

编译(没有opimization标志)到

     0: aload_0
     1: astore_3
     2: aload_3
     3: ifnull        21
     6: aload_3
     7: invokevirtual #35                 // Method scala/Tuple2._2$mcD$sp:()D
    10: dstore        4
    12: dload         4
    14: iconst_1
    15: i2d
    16: dadd
    17: dstore_1
    18: goto          33
    21: goto          24
    24: new           #37                 // class scala/MatchError
    27: dup
    28: aload_3
    29: invokespecial #41                 // Method scala/MatchError."<init>":(Ljava/lang/Object;)V
    32: athrow
    33: dload_1
    34: dreturn

对于匹配错误,有一个(无结果)测试。

一般来说,你认为可以接受多少开销是无法回答的。