最後の分岐レコードは、最近実行された分岐に関連するソース アドレスと宛先アドレスを格納するレジスタ ペア (MSR) のコレクションを指します。興味がある場合は、http://css.csail.mit.edu/6.858/2012/readings/ia32/ia32-3b.pdfドキュメントに詳細情報があります。
ペーパーIntelCodeExecution Trace Resources（Ariumワーカー、CraigPedersenおよびJeffAcampora、2012年4月29日）には、ブランチトレースの3つのバリエーションがリストされています。
DebugCtlMSRおよび対応するLastBranchToIPおよびLastBranchFromIPMSR、ならびにLastExceptionToIPおよびLastExceptionFromIPMSRのLastBranch Record（LBR）フラグ。
RAMとしてのキャッシュまたはシステムDRAMのいずれかを使用するブランチトレースストア（BTS） 。
XDPポートからキャプチャされ、接続されたターゲット内プローブに外部に保存されたアーキテクチャイベントトレース（AET） 。
2ページで述べたように、LBRはMSRに情報を保存しますが、「リアルタイムのパフォーマンスを妨げることはありません」が、非常に短いコードにのみ役立ちます（「効果的なトレース表示は非常に浅く、通常は数百の命令しか表示されない場合があります」）。 。4〜16個のブランチに関する情報のみを保存します。
BTSを使用すると、ブランチの「From」と「To」のペアを多数キャプチャして、キャッシュ（Cache-as-RAM、CAR）またはシステムDRAMに保存できます。CARの場合、トレースの深さ/長さはキャッシュサイズ（および一定の定数）によって制限されます。DRAMのトレース長はほぼ無制限です。このホワイトペーパーでは、追加のメモリストアが原因で、BTSのオーバーヘッドを20〜100パーセントと見積もっています。Linux上のBTSは、提案されたperfブランチレコード（まだバニラにはありません）またはbtraxプロジェクトで簡単に使用できます。perf branchプレゼンテーションは、BTS組織に関するいくつかのヒントを提供します。「from」、「to」フィールド、および「predictedflag」を含むBTSバッファーがあります。したがって、BTSを使用する場合、分岐予測はオフになりません。また、BTSバッファが最大サイズまでいっぱいになると、割り込みが生成されます。カーネル内のBTS処理モジュール（perf_eventsサブシステムまたはbtraxカーネルモジュール）は、このような割り込みが発生した場合に、BTSバッファーから他の場所にデータをコピーする必要があります。
したがって、BTSモードでは、2つのオーバーヘッドの原因があります。キャッシュ/メモリストアとBTSバッファオーバーフローからの割り込みです。
AETは、外部エージェントを使用してデバッグおよびトレースデータを保存します。このエージェントは、eXtended Debug Port（XDP）を介して接続され、In-Target Probe（ITP）とインターフェイスします。このホワイトペーパーによると、AETのオーバーヘッドは、「システムパフォーマンスに大きな影響を与える可能性があり、数桁大きくなる可能性があります」。これは、AETがより多くの種類のイベントを生成/キャプチャできるためです。ただし、収集されたデータストレージは、デバッグされたプラットフォームの外部にあります。
ペーパーの「要約」は次のように述べています。</p>
LBRにはオーバーヘッドはありませんが、非常に浅いです（CPUに応じて4〜16のブランチロケーション）。トレースデータはリセット後すぐに利用できます。
BTSははるかに深いですが、CPUパフォーマンスに影響を与え、オンボードRAMを必要とします。トレースデータは、CARが初期化されるとすぐに利用可能になります。
AETには特別なITPハードウェアが必要であり、すべてのCPUアーキテクチャで使用できるわけではありません。トレースデータをオフボードに保存できるという利点があります。