Cache the mate cigar the first time it is parsed on SamRecord

[clintval]

I'm starting to think we should cache the mate cigar like we do with the record's cigar. It would require similar trickery to detect when a new mate cigar is updated upon the record since we would have to intercept any call to setAttribute, check if the attribute is being set with the MC tag, and then reset the in-memory mate cigar to the new value. If I implement this suggestion, it will be in a separate PR.

This might be my next PR since we already have all Cigar stats cached after a single stat is accessed:

fgbio/src/main/scala/com/fulcrumgenomics/alignment/Alignment.scala

Lines 177 to 178 in 42aaae7

	/** Statistics about this cigar which are computed once on first access and then cached. */
	private lazy val stats: CigarStats = CigarStats(this)

From:

• Often ignore hard clipping when fetching unclipped ends #1065 (comment)

[tfenne]

I don't love this idea because unlike the primary CIGAR, this being an extended attribute, makes catching all changes to it far more complicated. If this is really a bottleneck I'd propose a slightly different solution along these lines:

private var _mateCigar: Option[Cigar] = None
private var _mateCigarStringParsed: String = ""

def mateCigar: Option[Cigar] = {
  val currentMc = this.get[String]("MC").getOrElse("")

  if (_mateCigar.isEmpty || !(currentMc eq _mateCigarStringParsed)) {
    if (currentMc != "") {
      this._mateCigar = Cigar.parse(currentMc)
      this._mateCigarStringParsed = currentMc
    }
  }

  this._mateCigar
}

[nh13]

We do still have to be careful to invalidate those fields when MC is updated right?

[clintval]

We do still have to be careful to invalidate those fields when MC is updated right?

If we make them private then we should be OK since they get checked the next time a user requests the parsed mate CIGAR.

I might suggest we name them more carefully so no one relies on them from within the class (e.g. _lastMateCigarParsed). But I like the idea because it would be a good speedup and is simple to implement. And yes, this is the next speed optimization for us to make in this part of the codebase as I've done some profiling and for code that accesses the unclipped coordinates of templates, we do a lot of redundant mate cigar processing from strings.