1. 引入

宏在Geotrellis中更类似于一种锦上添花的存在:没有它不会动摇整体的功能,使用它则会带来许多方便.

在官方文档中,宏的使用被放置在额外的high-performance-scala一节.如同官方文档所说,宏的存在是为了提高效率:

• 计算的效率:
  • 不使用传统的泛型,避免拆装箱的消耗.
  • 增强某些算法的速度.
• 编程的效率:
  • 提高某些代码的可读性.
  • 自动生成部分重复代码.

宏编程属于元编程领域,本身具有一定的难度和不稳定性,相关的功能也在随着Scala的演进而更新,因此在此并不十分深入展开.

2.类型转换中的宏

我们先回到上一篇解析GeotiffSegment扩展类的场景(以getInt方法为例,省略类似的getDouble方法):

// 无Nodata值模式
class Float32RawGeoTiffSegment(bytes: Array[Byte]) extends Float32GeoTiffSegment(bytes) {
  def getInt(i: Int): Int = get(i).toInt
}

// 使用固定Nodata值模式
class Float32ConstantNoDataGeoTiffSegment(bytes: Array[Byte]) extends Float32GeoTiffSegment(bytes) {
  def getInt(i: Int): Int = f2i(get(i))
}

// 使用用户自定义Nodata值的情况
class Float32UserDefinedNoDataGeoTiffSegment(bytes: Array[Byte], val userDefinedFloatNoDataValue: Float)
    extends Float32GeoTiffSegment(bytes)
       with UserDefinedFloatNoDataConversions {

  def getInt(i: Int): Int = udf2i(get(i))
}

具体的数据类型到Int的转换,存在三种处理函数:

• 无Nodata值:get(i).toInt
• 具有Nodata值:
  • 使用默认的固定Nodata值:f2i(get(i))
  • 使用用户自定义Nodata值:udf2i(get(i))

最简单的当属无Nodata值的情况,直接获取即可.当处理具有Nodata值的数据时,需要将所获取值与Nodata值做判断,因此在转换中需要在get方法的外面添加一层逻辑.

虽然只是一层类似于if (n == Nodata) Double.NaN else n.toDouble的简单判断,但对于Geotrellis这种面向大范围数据集处理场景而设计的工具,微小的性能损失积累起来也是值得警惕的.

所以我们可以观察到,f2i使用了宏定义:

def f2i(n: Float): Int = macro TypeConversionMacros.f2i_impl

object TypeConversionMacros
{
    def f2i_impl(c: Context)(n: c.Expr[Float]): c.Expr[Int] = {
    import c.universe._
    c.Expr(q"""{ val n = $n ; if(java.lang.Float.isNaN(n)) { Int.MinValue } else { n.toInt } }""")
  }
}

通过宏表达式不难看出,最终生成的方法在逻辑上与下列代码无异:

def f2i_(n: Float): Int ={
    if(java.lang.Float.isNaN(n)) { Int.MinValue } else { n.toInt }
}

与f2i对比,使用用户自定义Nodata值的转换方法udf2i就没有使用宏定义.既然如此,为何非要将f2i定义为宏函数,而不是普通函数呢?

原因在于在某些情况下,将代码转换为宏可以加速.在这篇文章里,讨论了使用宏优化过的Map操作相比原生Map操作巨大的性能优势.在本例中,代码内与NaN值相关的操作通过静态的类型分析,增强了各种内联优化,性能可以得到提升.而用户自定义Nodata值的情况无法享受到这种内联性能提升.

可以做个简单的实验:针对使用宏的方法f2i和功能完全一样的普通方法f2i_.执行百万次后,会发现宏方法对比普通方法有稳定的2%-3%的性能优势,随着执行次数的扩大,这个优势也将扩大.这种性能上的优势虽然小,但随着量的积累也将是可观的性能提升.

3. map操作中的宏

我们再回到类结构定义图.会发现在Tile类扩展了两个特质:

• MacroIterableTile
• MacroMappableTile

顾名思义,两者为Tile添加了遍历和map操作.我们以MappableTile为例:

trait MappableTile[T <: MappableTile[T]] extends MacroMappableTile[T] {

  def map(f: (Int, Int, Int) => Int): T =
    macro TileMacros.intMap_impl[T]
    
    // ... 省略类似的mapDouble
}

object TileMacros {
  // https://scalac.io/blog/def-hello-macro-world/
  // 为了实现泛型宏,里面的泛型促使全部要用c.Expr包裹起来
  def intMap_impl[T <: MacroMappableTile[T]](
      c: Context
  )(f: c.Expr[(Int, Int, Int) => Int]): c.Expr[T] = {
    import c.universe._
    // c.prefix.tree是当前的AST
    // self是当前MacroMappableTile[T]类型的AST执行后的结果,是一个标记了类型的AST
    val self = c.Expr[MacroMappableTile[T]](c.prefix.tree)
    // 执行语法树上的mapIntMapper方法
    val tree =
      q"""$self.mapIntMapper(new geotrellis.macros.IntTileMapper { def apply(col: Int, row: Int, z: Int): Int = $f(col, row, z) })"""
    new InlineUtil[c.type](c).inlineAndReset[T](tree)
  }
}

通过宏,在Tile对象上,就生成了如下的新方法:

def map(f: (Int, Int, Int) => Int):T = {
    self.mapIntMapper(new geotrellis.macros.IntTileMapper { 
        def apply(col: Int, row: Int, z: Int): Int = f(col, row, z) 
    })
}

除了上文提到的可以提高Map操作的效率外,mapIntMapper函数定义在Tile类的若干个子类中,map操作大同而小异,仅有些许细节不同,因此宏在这里也起到一个模板的作用,自动将相同主干与不同的细节结合生成方法,节省了代码量,也便于修改.

4. 总结

除了在代码中显示的使用宏,Geotrellis引入的处理数字的spire包也大量的使用了宏.宏虽然不方便调试和也不适于大范围编写,但在一些核心区域用宏替换普通方法,可能会有可观的性能提升.

至此,有关Geotrellis如何读取Geotiff文件的整体脉络大体上比较清晰了,主要分为两个步骤:

1. 读取元数据
2. 根据元数据构建一个[Celltype]GeotiffTile

而有关如何使用元数据构建GeotiffTile对象,又可划分为3个模型,我们分别解析其存在的目的与实现的功能:

• 数据类型模型
• Segment模型
• 宏模型

虽然忽略了一些具体函数和字段,但对于Geotiff对象的后续操作,最终还是会落实到这几个模型中.