游戲引擎學習第185天

回顧并計劃今天的內容

我們完成了開始整理這些數據的工作，但我們還沒有機會真正去查看這些數據的具體內容，因為我們只是剛剛開始了數據整理的基本工作。我們收集了大量的信息，但到目前為止，仍然沒有足夠的可視化工具來幫助我們理解這些數據。今天，我覺得會很有趣，因為我們已經為數據收集做了很多基礎工作，而接下來這一周，我們將能夠開始看到這些數據到底傳達了什么信息。

我們把代碼留在了一個無法工作的狀態

在我們上次停下的地方，我們剛剛編寫了一些數據整理的代碼，但實際上并沒有運行它，也沒有檢查它是否有效。說實話，我甚至不記得做了什么，我不確定我們是否運行過代碼，也許我們運行了。看起來我們確實沒有執行過這些代碼，因為如果執行了，我們應該已經發現當前幀是0。所以顯然，在處理數據整理時，我們實際上并沒有完成代碼的相關部分。因此，幀數是0，任何新的幀數據都將是垃圾數據，一旦我們嘗試寫入這些數據，就會導致崩潰。

現在，我們只是想繼續前進，完成這些代碼。就像我之前說的，我們已經開始了，但還沒有完成，所以下一步就是要把剩下的工作完成。這看起來沒有什么神秘的，但確實要做的事情比較多。因為我不記得上次到底做到了哪里，畢竟已經過了些時間。周末有很多工作需要做，今天也有很多工作要做，所以這段時間就好像已經忘記了之前的代碼。
在這里插入圖片描述

在這里插入圖片描述

回顧之前的代碼

這里是我們的調試幀。如果你還記得我們之前決定做的是，使用一個調試臨時區，就像一個可以隨意使用的內存區域，每一幀之后都會被丟棄。所以我們可以在這個區域內做任何事情，之后它會被重置。
在這里插入圖片描述

在這里插入圖片描述

當我們在初始化一切時，首先會創建這個臨時內存區域，然后調用 CollateDebugRecords 函數。CollateDebugRecords 允許我們使用這塊內存，并可以按照需要進行操作。你可以看到，函數將 frame_count 設置為零，但它并沒有實際初始化幀數據。因此，我們希望在這里做的事情是，我們可以直接去申請一些幀內存。

在這里我們可以添加一個推送操作，用來初始化這些幀。
在這里插入圖片描述

在這里插入圖片描述

將調試幀推入合并內存區

我們已經有了這個數組的整理方式，因此可以自由地對其進行操作。如果想要向其中添加一個數組，可以指定我們需要的幀數。當然，我們是知道幀數的，因為我們已經為其預留了一定的存儲空間。然而，奇怪的是，這里似乎并沒有真正使用它，這有點不尋常。因此，需要檢查是否已經定義了它。

我們確實有 MAX_DEBUG_FRAME_COUNT，因此可以直接使用它。此外，由于我們正在使用一個臨時緩沖區，還可以采用另一種方式——將幀以鏈式方式連接。如果采用鏈式連接的方式，就不需要事先確定幀數。這樣就可以避免預估幀數的問題，而是直接根據可用內存的大小來動態管理幀的存儲方式。

同時，這種方式也避免了不必要的內存分配問題，因為幀的數量完全由當前可用的內存空間決定，而不是固定的數量。這種方法更加靈活，可以根據實際需求動態調整幀的存儲方式，而不需要事先進行靜態分配。
在這里插入圖片描述

通過將MAX_DEBUG_FRAME_COUNT作為事件數組的大小，我們假設每幀只會發出一個結束事件。讓我們去掉這個限制

MAX_DEBUG_FRAME_COUNT 目前被用于事件計數（event count），但有趣的是，它假設每次只會有一個 frame end 事件。如果這一假設不成立，即在一個幀內部可能存在多個 frame end 事件，那么 MAX_DEBUG_FRAME_COUNT 可能就無法容納足夠的事件數組來正確計數幀數。

實際上，在幀內部完全可以包含多個 frame end 事件，因此 MAX_DEBUG_FRAME_COUNT 這個命名可能并不準確。更準確的描述應該是 事件數組的數量（event array count），而不是幀的數量（frame count）。這兩個概念在邏輯上并沒有直接的耦合關系，即不一定要保持同步。

這種情況有些奇怪，難以明確定義。例如，可以假設最多只能有 2 或 4 個 frame end 事件，但實際上代碼中并沒有任何機制阻止在單個事件數組（event array）內生成多個 frame end 事件。這意味著可能會出現 幀數（frames）比事件數組（event arrays）更多 的情況。

因此，目前的 MAX_DEBUG_FRAME_COUNT 可能不是最佳的術語，也許應該重新定義它，使其更準確地描述實際用途。接下來需要做的是……
在這里插入圖片描述

在這里插入圖片描述

分配debug_frames

現在需要分配一些調試幀（debug frames），因此首先進行內存分配，為這些幀創建一個存儲數組。不過，這里 不應該使用 max debug frame count，而是應該使用 事件數組的數量（MAX_DEBUG_EVENT_ARRAY_COUNT），因為它更符合實際需求。

在遍歷過程中，每次遇到幀標記（frame marker）時，當前幀指針（current frame）都會推進到一個新的位置。當指針前進后，就會有對應的有效內存可用。因此，每次遇到 frame marker，都會切換到一個新的調試幀，并確保其有合法的存儲空間。

此外，還需要關注 調試幀區域（debug frame regions），這是接下來要處理的一個關鍵部分。這些區域用于存儲和管理調試幀數據，確保調試過程中可以正確訪問和使用它們。
在這里插入圖片描述

分配debug_frame_regions

現在需要開始向 調試幀區域（debug frame regions） 寫入數據，因此必須確保有足夠的內存來分配這些區域。這些區域的作用是顯示和存儲調試幀的信息，因此首先需要思考如何進行分配。

為了給這些區域提供存儲空間，應該在 當前幀（current frame） 內部分配專門的區域。例如，可以在 CurrentFrame->Regions 中使用 PushArray 來分配內存。不過，也可以選擇不同的方式，比如 不使用 PushArray，而是采用更靈活的策略。目前暫時使用 PushArray，但之后可能會調整策略。

關于具體分配的大小，目前并不確定合適的值。例如，MAX_DEBUG_RECORD_COUNT 可能過大，因此暫時設定一個較合理的范圍。但這些值仍然是任意設定的，后續可能會調整，或者采用更動態的方式，而不是基于固定大小的數組。

可能更合理的方法是 按需分配內存，而不是預先分配固定大小的數組。當前的方法暫時可行，但未來可能需要優化。例如，可以使用 鏈式存儲（daisy chaining） 來動態管理這些區域，而不是一次性分配固定大小的數組。這樣可以 更高效地利用內存，避免浪費或分配不足的問題。因此，可能需要進一步調整策略，使其更加靈活和高效。
在這里插入圖片描述

測試。我們正在耗盡調試內存

現在已經有了存儲調試幀區域（debug frame regions）的地方，并且代碼可以正常編譯和運行。然而，在運行過程中，會遇到內存空間不足的問題。
在這里插入圖片描述

在這里插入圖片描述

部分原因可能是 調試存儲空間（DebugStorageSize） 預留得較小，導致無法存儲大量的事件數據。因此，目前的內存分配可能不夠支撐完整的調試過程。需要檢查 DebugStorageSize 的大小，并評估是否需要擴大存儲容量。
在這里插入圖片描述

在不清楚最佳方案的情況下，暫時可以采用 較小規模的分配 作為臨時解決方案，以便觀察程序的運行情況。然而，在當前大小的內存池（arena）下，能做的事情非常有限，因此可能需要調整策略。

另外，編譯器報錯指出 current frame region 沒有正確分配，需要檢查是否正確初始化和分配了內存。可能是某個分配步驟遺漏了，或者分配邏輯存在問題，需要進一步排查。
在這里插入圖片描述

錯誤的原因是什么？我們處理了太多幀嗎？

現在已經成功創建了調試幀（debug frames），但在檢查幀數（frame count）時，發現 幀的數量遠超預期，這表明可能存在某種 bug。

具體來看，當前的 事件索引（event rate index） 為 3，而 有效事件（valid event） 僅為 1，但幀數卻異常地增長過高，這與預期不符。因此，當前的幀計數邏輯可能存在錯誤，需要進一步排查。

在遍歷事件的過程中，每次都會添加一個新的幀，但當前的行為表明某個地方可能存在重復添加或錯誤計算。接下來需要檢查：

事件的遍歷邏輯：是否在不應該增加幀數的地方錯誤地增加了幀數？
事件存儲機制：是否在存儲事件時發生了錯誤，導致幀數異常？
索引計算方式：當前索引 (event rate index) 是否被正確更新，是否有可能導致幀數重復計算？

當前這種行為明顯不符合預期，因此需要對代碼進行詳細檢查，以找出導致幀數異常增長的具體原因。

我們把整個事件數組當作已經填充了真實事件來處理！

問題出在 循環遍歷事件索引的方式，當前的遍歷邏輯是錯誤的，因為它并沒有限制在 實際存在的事件索引范圍內，導致幀數異常增長。因此，需要修正遍歷邏輯，使其只遍歷 實際存在的事件，而不是超出范圍的無效索引。

當前的錯誤導致了幀數計算出現 不合理的增長，這種行為是不正確的。修正后，循環將僅針對 有效事件索引 進行迭代，從而確保計算出的幀數是合理的。

修復該問題后，整個系統應該會恢復正常，幀數的計算也會更加準確。
在這里插入圖片描述

在這里插入圖片描述

游戲現在可以運行了

現在代碼已經處于較為穩定的可運行狀態，因此可以繼續優化數據整理（collation）部分的邏輯。由于整理數據的過程較為復雜，因此需要深入分析其具體實現方式。

接下來需要確定如何有效整理這些數據，以便更好地管理和存儲它們。這一部分的邏輯相對棘手，因此需要仔細研究接下來的操作流程，確保數據整理能夠正確進行，并優化內存使用情況。

（黑板）配對開始和結束事件時我們會遇到的問題

當前的問題是 調試事件（debug events） 沒有明確的結束時間。例如，當遇到 begin block 事件時，并不知道何時會遇到對應的 end block。因此，需要將這些事件正確配對，以便進行數據整理（collation）。

目前已經有 調試記錄索引（debug record index），可以用來輔助匹配 begin 和 end 事件。但需要建立一個整理區域（collation space），用于存儲和管理這些配對信息。

事件配對的復雜性

遞歸調用的問題
- 例如，假設存在一個函數 foo()，它在執行過程中可能遞歸調用自身。
- 這樣，在 foo() 完成前，它可能已經多次觸發 begin foo 事件，而 end foo 事件只有在遞歸返回時才會出現。
- 這導致 begin foo 事件可能會連續出現，必須確保匹配正確的 end foo。
多線程環境的問題
- 由于可能存在多個線程，每個線程都會獨立產生 begin 和 end 事件。
- 不能簡單地按順序匹配所有 begin 和 end 事件，而是需要按照線程 ID 進行分組，確保同一線程內的 begin 和 end 事件正確配對。
- 例如，在兩個線程 thread 0 和 thread 1 運行時，它們可能分別觸發 begin foo 和 end foo，但它們不應該跨線程匹配。

正確的事件匹配方式

按照線程 ID 進行分組，確保 begin 和 end 事件僅在相同的線程內匹配。
使用棧結構（Stack） 來存儲 begin 事件，當遇到 end 事件時，從棧頂彈出并匹配。
遞歸調用時，按照調用深度匹配，確保 begin foo 和 end foo 的配對關系正確。

示例匹配邏輯

假設事件日志如下：

Thread 0: Begin Foo  
Thread 1: Begin Foo  
Thread 0: End Foo  
Thread 1: Begin Foo  
Thread 1: End Foo  
Thread 1: End Foo

錯誤匹配（不考慮線程 ID）

Thread 1: Begin Foo  --Thread 0: End Foo  ?（錯誤，因為它們屬于不同線程）

正確匹配（按線程 ID 分組）

Thread 0: Begin Foo  -- End Foo  ?
Thread 1: Begin Foo  -- End Foo  ?
Thread 1: Begin Foo  -- End Foo  ?

下一步

實現一個整理區域（collation space） 來存儲 begin 和 end 事件，并按照線程 ID 進行分類。
使用棧結構 來處理 begin 和 end 事件的匹配，確保遞歸調用可以正確解析。
優化數據存儲，減少不必要的遍歷，提高匹配效率。

總的來說，當前的挑戰是確保 begin 和 end 事件能正確匹配，特別是在遞歸和多線程環境下，這需要更加精確的分組和存儲策略。

我們將通過線程和計數器ID的組合來識別事件。我們將使用堆棧來配對它們

在讀取這些調試事件時，需要確定它們的唯一標識，并找到正確的配對方式。

唯一標識的構造

每個事件都有計數器索引（counter index），并且該索引具有唯一的 ID。
線程 ID（thread ID）+ 計數器 ID（counter ID） 形成一個唯一標識，可用于匹配 begin 和 end 事件。
事件匹配的目標是找到相同 thread ID + counter ID 的 begin 和 end 事件，確保它們正確配對。

匹配策略

為了高效地匹配 begin 和 end 事件，考慮使用棧（stack）結構：

每個線程維護一個獨立的棧，存儲該線程的未匹配 begin 事件。
遇到 begin 事件，將其推入對應線程的棧中。
遇到 end 事件，在該線程的棧中從后往前搜索，找到最近的匹配 begin 事件并彈出。
確保 LIFO（后進先出）順序，即 end 事件始終匹配該線程最近的 begin 事件。

避免復雜的數據結構

雖然可以構建一個 線程 ID × 計數器 ID 的二維結構，其中每個單元是一個鏈表存儲未匹配的 begin 事件，但這可能過于復雜且資源占用較大。
由于大多數 begin 事件都會很快匹配到 end，且嵌套深度不會太大，因此使用簡單的棧存儲每個線程的未匹配 begin 事件，可以大幅減少復雜度和查找成本。

處理嵌套和交錯匹配

在同一線程內，正常的匹配方式是：

begin foo (thread 0)
begin bar (thread 0)
end bar (thread 0)
end foo (thread 0)

這種情況下，棧的行為如下：

[foo]  → push bar → [foo, bar]
[foo, bar] → pop bar → [foo]
[foo] → pop foo → []

匹配順序正確 ?

但如果發生錯誤的交錯匹配：
```
begin foo (thread 0)
begin bar (thread 0)
end foo (thread 0) ?  # foo 結束了，但 bar 仍未結束 必須是棧頂
end bar (thread 0)
```
這會導致錯誤匹配：
```
[foo]  → push bar → [foo, bar]
[foo, bar] → pop foo ?  # 不應該先彈出 foo，bar 還沒結束 必須是棧頂
```
需要一種機制來檢測并防止錯誤匹配，例如：
- 嚴格約束嵌套順序，確保 end 事件只能匹配棧頂的 begin 事件，否則報錯。
- 提供調試警告，提示 end 事件的匹配順序錯誤。

優化方案

限制每個線程內的嵌套規則，避免錯誤的交錯匹配。
棧的存儲方式可以使用鏈表，這樣可以動態擴展，而不必預先分配固定大小的數組。
若嵌套層數過深，可以考慮定期清理或優化存儲結構，防止過多的 begin 事件堆積導致內存消耗過大。

總結

使用 thread ID + counter ID 作為唯一標識，確保 begin 和 end 事件正確匹配。
采用 per-thread 棧結構，存儲該線程的未匹配 begin 事件，提高匹配效率。
嚴格遵循 LIFO 規則，防止 begin 和 end 事件的錯誤匹配。
提供錯誤檢測，防止 begin 和 end 交錯匹配。
避免不必要的復雜數據結構，以簡潔高效的方式完成事件匹配。

禁止重疊的開始/結束配對塊

在處理調試事件時，遇到了一種情況，其中多個事件可能在同一線程中交替開始和結束，導致這些事件并不總是按“最后一個打開的事件先關閉”的規則匹配。這種情況被稱為“交錯”，也就是開始一個事件后再開始另一個事件，然后結束最外層的那個，而不是最內層的。

交錯匹配問題

如果不允許這種交錯行為，每次都會匹配最新打開的事件，即最內層的事件先結束。但如果允許交錯，可能會出現一些異常，特別是當事件在同一線程中重疊時。
在可視化中，這種重疊可能導致時間條（bar）重疊，這使得我們難以在圖表中正確表示每個事件的時序，因為事件的時間段可能部分交叉。

是否允許交錯匹配

不允許交錯匹配：可以避免這種重疊情況，使得每個事件的時間條更加清晰，且符合通常的閉合順序（先打開的事件先關閉）。這種做法有助于簡化可視化，因為每個事件都有明確的開始和結束時間，不會互相穿插。
允許交錯匹配：雖然支持交錯行為不會導致系統本身出現問題，但它確實使得可視化變得更加復雜。為了在圖表中顯示多個重疊事件，可能需要更多的“時間條層”來表示這些重疊的事件。如果不同事件的時間段在同一線程中交叉，就可能導致不易理解的圖形表示，特別是在存在多個線程時。

可視化與簡化的考慮

如果不允許交錯匹配，每個事件的時間段會更加分明，使得圖表中每個線程的活動容易理解，不會有事件重疊的困擾。
如果允許交錯匹配，雖然能夠處理更復雜的情況，但圖形呈現上會變得難以閱讀，需要更多的圖層或復雜的可視化技術來展示。并且，這可能會使得標準的事件嵌套和閉合規則變得不再適用。

處理方式

為了避免這些復雜性，可以選擇在系統中強制禁止交錯匹配，即確保每個事件按照“先進后出”的規則匹配。這樣不僅能避免事件的重疊，還能使得可視化變得更加清晰和易于理解。通過這種方式，也可以更容易地查看各個線程的活動，并確保所有事件在邏輯上按照正確的順序進行。

結論

如果不允許事件交錯，可以簡化可視化，避免重疊并讓圖表更加直觀。
允許交錯匹配雖然能夠處理更復雜的場景，但可能導致圖形表示上的復雜性，需要更多的圖層來顯示重疊事件。
在實際操作中，可能更傾向于禁止交錯匹配，從而使可視化更加簡潔、清晰，同時也不影響系統的功能性。

分配存儲空間以配對調試塊的堆棧

在處理調試事件時，需要為每個調試塊（debug block）分配一個open_debug_block，這個結構體包含一些指針，用于指向該調試塊的父級（即上一個塊）。每個調試塊的信息大致與調試事件結構體中的信息相同。為此，可以將調試事件結構體本身作為該開放塊的一部分。

設計思路

開放調試塊：每個open_debug_block會包含指向父調試塊的指針，這樣可以形成一個樹形結構，允許追溯到更早的調用或事件。這也意味著在調試過程中，如果需要從某個點追溯其父級或其他相關信息時，可以通過父指針進行訪問。
信息存儲：每個調試塊中存儲的內容大致相同，主要包括事件的開始信息。具體的事件開始時，創建一個open_debug_block，并在該塊內記錄調試事件的具體信息。
結束事件匹配：當結束事件發生時，就會找到對應的開始事件，二者可以進行配對，進行后續處理。具體來說，在配對過程中，開始事件和結束事件會被合并（collapse），然后可以進行進一步的操作，比如數據記錄、狀態更新等。

線程管理

每個線程一個調試塊：對于每個線程，都需要有一個獨立的調試塊來跟蹤該線程的調試事件。為了確保線程之間的調試事件不會相互干擾，每個線程的調試事件都被獨立管理，并且可以單獨跟蹤。
線程ID管理：每個線程的調試塊會包含該線程的唯一標識符（線程ID）。在初始化調試過程時，會為每個線程創建一個調試塊，并且確保線程ID的管理與調試塊的創建保持一致。

實現思路

可以為每個線程分配一個最大數量的調試塊。雖然目前可能不需要太多線程支持，但未來的硬件（例如Xeon Phi等）可能會支持更多線程，因此可以預留一個相對較大的上限來應對未來的需求。
調試塊初始化：在調試過程的初期，每個線程會初始化一個調試塊，并記錄該線程的ID。然后，在調試過程中，所有的事件都會根據該線程的ID進行匹配，并通過線程的調試塊來進行跟蹤。

通過這種方式，每個線程的調試事件都能夠獨立管理，確保線程間的調試信息不會混淆，同時也可以便捷地進行配對和后續處理。
在這里插入圖片描述

在這里插入圖片描述

使用debug_thread將調試塊按源線程進行隔離

為了優化調試過程中的線程管理，考慮將調試線程（debug thread）和線程ID信息整合到一個新的數據結構中，名為debug_thread。該結構將包含線程ID和該線程的第一個調試塊信息。通過這種方式，可以創建一個調試線程數組，便于管理每個線程的調試塊和其相關的調試事件。

設計思路：

調試線程結構：每個debug_thread結構將包含線程ID和該線程對應的第一個調試塊。這讓每個線程的調試塊得到了獨立管理，便于調試過程中的追蹤和操作。
調試線程數組：將多個debug_thread結構存儲到一個數組中，允許動態擴展線程數，避免固定的線程數限制，增加靈活性。這樣，調試過程中可以根據需要動態管理線程。
初始化調試線程：在調試開始時，為每個線程初始化debug_thread，并將其添加到調試線程數組中。這樣，可以避免一開始就為每個線程分配固定數量的資源，而是動態分配。
線程處理：在調試過程中，訪問特定線程時，不再通過固定的調試狀態來獲取，而是直接通過調試線程數組來檢索每個線程的信息。
線程索引管理：每個debug_thread將包含一個LaneIndex，用于標識該線程的調試塊位置。這個索引可以直接從調試線程中獲取，從而簡化了線程的查找和管理。
調試狀態和線程配對：在進行begin block和end block配對時，不再依賴于調試狀態中的復雜邏輯，而是利用debug_thread中的信息來匹配每個線程的事件。這種方式使得線程配對更加高效，避免了不必要的復雜操作。
性能優化：避免了每次都初始化固定數量的線程資源，而是動態管理和分配，使得在多線程調試場景下，系統的內存和資源使用更加高效。

通過這種設計，可以在調試過程中動態管理線程，靈活擴展線程數，并且確保每個線程的調試事件都能夠得到準確的匹配和處理。
在這里插入圖片描述

在這里插入圖片描述

處理DebugEvent_BeginBlocks

在處理調試塊（debug block）時，對于每個begin block，會創建一個新的調試塊結構。每當遇到begin block時，就會在調試狀態的內存區域（debug arena）中推入一個新的調試塊，并進行管理。具體來說，執行過程中會有如下步驟：

初始化和回收：在初始化階段，會將調試狀態的“第一個空閑塊”指針（FirstFreeBlock）設置為零。這意味著在開始時，調試狀態沒有可用的空閑塊。每當新塊被創建時，會將其插入到內存區域，并更新空閑塊指針。
創建新的調試塊：當遇到begin block時，首先檢查當前是否有空閑的調試塊。如果有，就將空閑塊指針指向一個有效的調試塊，并將空閑塊指針更新為下一個空閑塊。這樣，新的調試塊就被成功創建并推入調試狀態中。
沒有空閑塊時的處理：如果當前沒有空閑的調試塊（即FirstFreeBlock為null），則通過結構體推送（push struct）的方式創建一個新的調試塊，并將其分配給debug block。創建完新的調試塊后，會更新調試狀態的空閑塊指針，指向下一個可用的塊。
調試塊管理：在整個過程中，通過動態管理空閑塊的方式來避免頻繁地分配和釋放內存。這種方式不僅提高了內存使用效率，而且可以保證每次遇到begin block時都能為其分配一個有效的調試塊，并在調試完成后回收這些塊。

通過這種方式，調試過程中的調試塊能夠高效地被創建和管理，確保在多次調試事件中能夠不斷復用已有的內存塊，從而避免頻繁的內存分配操作，提高系統性能。
在這里插入圖片描述

在這里插入圖片描述

設置debug_blocks的值

在處理調試塊時，需要將調試塊的各個值設置為我們實際要記錄的信息。具體操作如下：

設置當前事件指針：當前處理的調試塊事件就是當前正在處理的事件，因此要將該事件指針與當前的調試塊事件進行關聯。
記錄父塊信息：每個調試塊都會有一個父塊，即在當前調試塊之前已經打開的調試塊。由于每個線程都有一個打開塊的堆棧（stack），我們可以通過訪問這個堆棧的第一個元素來確定當前塊的父塊。即，當前父塊是線程堆棧中最先打開的那個調試塊，因為它是調用當前塊的上一個塊。
設置當前塊的相關信息：一旦確定了當前塊的父塊，就可以更新當前塊的指針，關聯到其父塊。同時，還可以將當前塊的下一個塊指針（next）設置為零，雖然這并不會被后續操作所使用，但設置為零只是為了確保數據的清晰性和一致性。
清空無用指針：有些無用的指針可以設置為零，比如next指針，盡管在后續過程中不會訪問這個指針，依然可以將其歸零以保持結構的整潔。

總結起來，處理調試塊的過程包括確定當前事件指針、獲取父塊信息并將其與當前塊關聯，以及在必要時清空無用的指針。這些操作確保了調試塊的正確管理和組織。

在這里插入圖片描述

在DebugEvent_EndBlock中，我們將找到匹配的塊（如果有的話），并將其移除

在結束一個調試塊時，需要執行與開始調試塊相反的操作。具體步驟如下：

匹配結束塊：當遇到結束塊時，首先需要找到與之匹配的開始塊。匹配的塊應該是當前線程上最后一個打開的塊。為了進行匹配，可以通過斷言來檢查它們是否匹配，或者編寫一個方法來搜索并找到匹配的塊。
斷言匹配：在初期，確保找到匹配的塊，避免過多的復雜操作。檢查匹配時，需要確保線程ID、調試記錄索引以及翻譯單元（Translation Unit）等字段都與當前事件一致。如果這些信息都匹配，那么就說明這兩個事件是配對的。
處理無匹配塊的情況：有時可能沒有找到匹配的開始塊，尤其是當某個塊在多幀之前打開，而這些幀已經超出了事件記錄范圍時。在這種情況下，可以選擇記錄一個特殊的事件，表示該結束塊沒有對應的開始塊。這種情況下的可視化處理可能需要做出一些特殊的設計，例如用一個橫跨整個時間軸的條形表示這個未配對的結束塊。
匹配成功后的操作：當成功匹配到對應的開始塊時，可以將這兩個事件視為成對事件，執行相關的操作（如關閉調試塊、記錄配對信息等）。這種處理保證了塊的正確匹配和事件的順序管理。

總體來說，結束塊的處理涉及到匹配開始塊，檢查是否存在匹配，處理沒有匹配塊的特殊情況，并對匹配成功的塊執行關閉和記錄操作。這些操作確保了調試塊的正確配對和事件的順序性。

在這里插入圖片描述

查找與BeginBlock匹配的EndBlock的幀索引

在處理調試塊時，首先需要關注開始事件發生的幀索引。特別是當開始和結束事件發生在不同的幀時，需要額外的工作來記錄這些事件的跨度。具體步驟如下：

記錄開始幀索引：在處理調試塊的開始事件時，需要記錄當前的幀索引。這可以通過記錄 frame index 來實現，表示該調試塊的開始幀。
檢查幀是否一致：當我們處理調試塊時，需要檢查開始事件的幀索引和結束事件的幀索引是否相同。如果兩者屬于同一幀，直接按照標準方式處理即可。如果它們屬于不同的幀，則需要分別處理跨幀的情況。
跨幀處理：如果開始和結束事件發生在不同的幀上，需要額外處理兩幀之間的跨度。可以將這個跨度分成兩部分：一部分是從開始幀到結束幀之間的跨度，另一部分是從開始事件到結束事件之間的完整跨度。這樣做需要在記錄時分開處理這兩個幀區間。
標準情況：如果開始和結束事件發生在同一幀上，那么處理起來會簡單很多，只需要按照正常的跨度記錄方法來處理。

總結來說，關鍵是在開始事件時記錄當前幀的索引，并根據開始和結束事件的幀索引是否一致來決定如何處理跨幀的情況。如果發生跨幀事件，就需要分兩部分處理每個幀之間的跨度，這樣才能準確記錄調試塊的時間范圍。
在這里插入圖片描述

在這里插入圖片描述

一旦找到EndBlock，我們就會繪制調試區域

在處理調試區域時，通常的情況是我們只關注同一幀內的調試信息，因此大部分情況下，我們會在同一幀內插入一個“調試條”來表示時間區間。以下是具體的處理過程：

添加調試區域：我們首先需要在當前幀中添加一個調試區域。這通常涉及到在調試狀態下（debug state）和當前幀（current frame）中插入一個新的調試區域。具體如何操作，可能需要檢查具體的繪制方式和代碼實現。
確定信息參數：當添加調試區域時，需要明確幾個參數：
- Lane Index：這是當前線程的 Lane 索引，因為所有屬于該線程的事件都會被映射到該 Lane 上。
- Min 和 Max T：這表示時間區間的開始和結束時間。我們需要將這些時間映射到當前幀的總時間區間。具體的映射方式可能依賴于如何將時間值規范化（比如是否使用 0 到 1 的范圍）。
繪制調試區域：一旦確定了 Lane Index 以及 Min 和 Max 時間值，就可以將這個調試區域繪制到當前幀中。具體的繪制方式可能需要參考現有的繪制代碼，特別是如何處理時間的映射和顯示。

總的來說，主要的操作是將調試信息插入當前幀，并根據當前幀的時間區間映射來確定每個事件的時間范圍，并最終繪制到正確的位置。這是調試過程中的常見操作，尤其是在同一幀內的處理。
在這里插入圖片描述

我們將根據幀的開始和結束時鐘值來規范化條形圖的大小

在繪制調試區域時，選擇如何處理和呈現時間值（如最小時間和最大時間）是關鍵。首先，我們需要確定時間值的表示方式，可以使用相對時間（從當前幀開始的時鐘值），這將使得時間范圍更加易于處理。

主要步驟包括：

使用相對時鐘值：通過將事件的開始時間和結束時間與當前幀的開始時間（即相對時鐘）進行比較，可以得到一個更小、更易處理的時間范圍。這樣，時間值不再是一個巨大的絕對值，而是一個較小的相對值，便于在調試區域內進行繪制。
選擇存儲格式：我們可以將這些時間值轉化為浮動點數值（比如 real64 或 real32），以便在繪圖時進行操作。使用 64 位或 32 位浮動點數可以幫助我們處理這些值，并保持一定精度，同時避免了直接使用 64 位整數帶來的復雜性。
優化時間范圍的繪制：在繪制調試區域時，可能會根據實際情況來選擇是否繪制某些時間區間。如果時間區間的大小較小，可能就不需要繪制它，避免影響性能。
逐漸深入的堆棧視圖：為了便于調試和觀察，我們可能希望將時間區間按層次進行繪制，逐漸深入到堆棧的每一層。這意味著只查看堆棧中某一層的事件，而不是所有事件的平鋪展示。
優化時間范圍映射：當繪制時間區間時，可能會對不同時期的時間進行映射和標準化。這包括根據幀的時間范圍調整調試區域的大小，使其與相對時間軸對齊，確保在圖表中可以正確顯示。

總的來說，核心目標是優化時間值的處理，避免過大的整數，使用相對時鐘和浮動點數表示，以便更精確地控制調試信息的繪制和展示。此外，通過逐層堆棧查看，能夠更清晰地展示和調試每個時間段的事件信息。
在這里插入圖片描述

目前我們只會繪制頂級塊

為了實現只記錄頂層調試塊的功能，需要確保調試塊的父級為空，才能視其為頂層函數。這意味著每當打開一個調試塊時，需要檢查其父塊。如果該調試塊的父塊為空，則表示這是一個頂層函數；如果父塊不為空，且父塊本身也沒有父塊，那么這個調試塊就屬于第二層函數。這個邏輯將幫助定義哪些調試塊屬于“頂層”，并將這些塊展示在圖表上。

主要步驟包括：

檢查頂層調試塊：每當處理一個調試塊時，首先檢查它的父級。如果該塊的父級為空，表示這是頂層函數的調試塊。只有這些頂層調試塊會被記錄在圖表中。
逐步擴展父級定義：為了能夠處理更深層次的調試塊，可以逐漸添加更多的規則來定義哪些塊屬于頂層。例如，若一個塊的父塊存在且該父塊沒有父塊，這表明這個塊是第二層深度的函數，依此類推。
修改調試線程管理：在實現過程中，需要修改一些管理調試線程的功能，例如 GetDebugThread 和 FirstFreeBlock，這些函數的實現需要調整和優化，以便正確地分配和管理調試塊的資源。
匹配結束塊：當找到一個結束塊時，需要確定它匹配的開頭塊。這可以通過對比線程 ID 和其他關鍵字段來實現，確保對應的開始塊和結束塊是配對的。
記錄和繪制圖表：當確認某個調試塊是頂層塊時，可以將其繪制在圖表中，顯示其在時間軸上的位置。隨著進一步的開發，可以擴展和改進這些邏輯，以支持更多層次的堆棧查看和不同深度的調試塊展示。

通過這種方式，可以逐漸實現更復雜的調試信息記錄和展示機制，使得對多層函數調用和調試信息的管理變得更加清晰和有效。
在這里插入圖片描述

在這里插入圖片描述

從堆棧中移除匹配的塊

在處理調試堆棧時，當匹配到一個結束塊時，需要移除該塊，以防止堆棧無限增長。具體來說，我們需要做以下操作：

移除匹配塊：找到匹配的結束塊后，應該將其從當前線程的堆棧中移除。這可以通過將 Thread->FirstOpenBlock 設置為該匹配塊的父塊來實現，進而把當前塊從堆棧中彈出，防止堆棧持續增長。
釋放已移除的塊：當匹配塊被移除后，它應該被添加到一個“空閑堆棧”（free stack）中，以便之后能夠重復使用這些調試塊結構，而不是每次都重新分配新的結構。
調整指針：在操作過程中，需要將 Thread->FirstOpenBlock 的指針更新為該匹配塊的父塊，確保正確管理堆棧結構，同時確保移除該塊后不會影響到其他塊的處理。

    Thread->FirstOpenBlock->NextFree = DebugState->FirstFreeBlock;DebugState->FirstFreeBlock = Thread->FirstOpenBlock;Thread->FirstOpenBlock = MatchingBlock->Parent;

未實現的功能：這些操作涉及到一些關鍵函數的實現，例如 GetDebugThread 和處理堆棧結構的部分。目前還需要具體實現這些函數，才能完成整個調試堆棧的管理。
區域添加：對于如何添加區域（AddRegion）的部分，目前還不完全明確，可能需要根據具體需求進一步定義其工作方式。

總體而言，整個過程的核心是保證堆棧的有效管理，防止堆棧無限增長，同時也能確保每次結束塊匹配時，相關的數據結構得到正確的更新和釋放。
在這里插入圖片描述

實現GetDebugThread

這個過程涉及到如何通過線程ID查找并管理調試線程。具體步驟如下：

查找線程：首先，我們需要通過線程ID來查找目標線程。調試狀態中維護了一個線程列表，遍歷該列表，檢查每個線程的ID。如果找到與給定ID匹配的線程，那么就找到了我們需要的線程。
未找到線程時的處理：如果遍歷完所有線程后，沒有找到匹配的線程ID，那么說明當前沒有該線程的調試記錄。在這種情況下，需要創建一個新的調試線程結構。
創建新的調試線程：為了創建新的線程，我們可以從一個“推送結構體”（PushStruct）中獲取，并通過結構體分配來初始化一個新的調試線程。新的線程會添加到調試狀態的線程列表中，從而進行跟蹤。
更新調試狀態：新的線程被創建后，我們需要確保它正確地鏈接到調試狀態中，保證調試狀態能夠正確管理每個線程。特別是需要更新相關的指針和鏈表結構，確保線程信息能夠被正確跟蹤和管理。

通過這些操作，調試線程將能夠在調試過程中得到正確的創建和管理，從而能夠在運行時有效地跟蹤和記錄每個線程的調試信息。
在這里插入圖片描述

在這里插入圖片描述

實現AddRegion

在這個過程中，主要目標是實現調試區域（debug region）的添加，同時確保性能不會受到過多影響。步驟如下：

添加區域：首先，解決添加區域的問題。需要確定把區域數據放在哪里，并使用一種簡化的方法進行實現。當前的思路是，假設每個區域的存儲結構類似于某種數據結構，我們可以通過驗證當前幀區域計數是否小于每幀允許的最大區域數量來判斷是否可以添加新的區域。
最大區域數量：為了避免在每幀區域數量上產生問題，可以設置一個“最大區域數量”的限制。如果當前幀區域數量超過該最大值，就需要進行相應的處理，例如通過鏈式結構管理區域，而不需要為每個區域固定一個上限。
性能考慮：需要注意的是，這種調試代碼不需要過度擔心性能優化，因為它主要用于調試，并不面向生產環境。然而，仍需確保它不會顯著影響幀時間，否則會降低使用的頻率。因此，盡管我們可以使用簡化的方法來實現，但在設計時要保持一定的性能意識。
框架標記和時間設置：每幀都有開始和結束時間（begin clock 和 end clock），需要根據這些時間信息來處理幀的顯示。在設置這些時，可以使用開始和結束時間來計算每幀的持續時間。這有助于將每個區域的顯示正確映射到幀的時間范圍內，雖然目前的實現方法可能對可視化效果不太理想，但至少能顯示預期的信息。
調試區域初始化：當成功獲得一個區域時，所有相關的數據（如區域的大小）都會被初始化。雖然目前的實現方法可能較為簡單，但這是為了確保最基本的功能能夠正常運行。
幀條縮放問題：當前幀條的縮放值尚未確定，需要進一步思考如何設置。雖然這暫時不完美，但至少可以通過初步的實現查看調試信息，以便后續進行優化和調整。

綜上所述，當前的重點是在調試過程中正確地記錄區域數據，并確保調試代碼不會對性能產生過大影響。
在這里插入圖片描述

在這里插入圖片描述

使用幀的時鐘范圍來縮放條形圖

在這一部分，主要目標是根據幀的開始和結束時間來確定一個合適的時間范圍，并用來設置幀條的縮放比例（frame bar scale）。

時間范圍計算：首先，確定當前幀的時間范圍，即幀的開始時間和結束時間之間的差值。這個差值表示幀所占的總時間。
幀條縮放比例：為了將時間范圍映射到一個標準的范圍（從 0 到 1），可以通過將 1.0 除以該時間范圍來計算幀條的縮放比例。這樣，時間范圍越大，幀條的縮放比例越小，反之亦然。
檢查時間有效性：在計算幀條的縮放比例之前，需要檢查時間范圍是否大于零，以確保該幀確實有時間占用。如果時間范圍為零，說明該幀沒有有效的時間數據，無法計算縮放比例。
目的：通過這種方式，可以將每幀的時間范圍映射到一個標準的 0 到 1 的區間內，這樣就可以根據這個比例來繪制幀條，從而實現更直觀的可視化展示。

簡而言之，當前的目的是通過計算每幀的時間范圍并將其映射到 0 到 1 的比例范圍內，來設置幀條的縮放比例，使得幀的時間占用可以在可視化中得到準確展示。

在這里插入圖片描述

測試。游戲似乎無限循環并掛起

問題出在意外地把一個線程重新關聯到了自己，造成了循環依賴的問題。經過檢查，發現并沒有直接出現預期的錯誤，實際上是線程關聯的方式不正確，導致了這種情況的發生。需要進一步修正這個錯誤，以確保線程的正確關聯，并避免引發更復雜的問題。
在這里插入圖片描述

錯誤是因為我們沒有初始化線程ID

在啟動過程中，發現了一個問題：線程ID沒有被正確初始化，這是一個疏忽。要查找這些線程時，必須確保正確設置它們的值，而不是讓它們保持默認值或零。為了確保能夠匹配到正確的線程ID，需要在啟動時正確地初始化這個ID。

此外，還沒有將第一個打開的塊（FirstOpenBlock）設置為零，這也是缺失的操作。我們應該在啟動時做這些必要的初始化，而不是僅僅接收默認的切換器。

至于 lane 索引，它應該是根據 DebugState->FrameBarLaneCount 來遞增的，debug state 中的 FrameBarLaneCount 將隨著每個線程的遞增而改變，確保每個線程有其獨立的 lane 索引。
在這里插入圖片描述

仍然無法正常運行

在處理調試過程中，發現了一個潛在問題。當前的一個問題是，頂級區域的數量似乎比預期要多得多。根據現有的實現，不應有那么多的區域，因為我們僅僅關注頂級區域。頂級區域應當只有少數幾個，因為只會有少數的打開和關閉事件發生。

不過，也有可能是因為包含了其他線程的區域，這些線程可能并不在其他區域內部。因此，它們可能會頻繁地打開和關閉，導致區域數量更多。雖然這聽起來不太可能，但考慮到這一點，仍然打算繼續觀察一段時間，看看實際情況如何。

為了進一步驗證，可以嘗試將每幀的最大區域數量設置為較大的值，看看系統如何處理這些區域，是否能正常工作。這將有助于了解系統的行為和可能存在的問題。
在這里插入圖片描述

步進調試代碼

為了調試和解決問題，需要進入程序并查看當前的狀態，特別是關于幀條比例的設置。首先，通過查看幀條比例，可以幫助了解一些調試信息。然而，回想起來，之前的做法有些不太妥當。

保持最大的FrameBarScale來縮放調試條形圖

在調試過程中，意識到之前沒能正確保留最大的時鐘范圍，這導致了幀條比例的設置錯誤。為了解決這個問題，決定在代碼中增加判斷，如果當前的幀條比例大于之前的值，就更新它，使得幀條比例隨著時間的推移逐漸增寬。這樣做是為了確保幀條比例能夠反映出真實的時間跨度。

接下來，檢查了幀條比例的值，確認了它的范圍是合理的，大約是4700萬，考慮到使用的是TTS CSR時鐘，這是一個合適的值。然后，查看了當前的幀和區域信息，發現有62個區域，每個區域的開始和結束時間看起來正常，因此計算結果看起來沒有問題。

最后，嘗試繪制這些區域，但沒有看到任何圖形輸出。檢查代碼后，意識到可能是因為繪制的代碼沒有正確測試或實現，導致圖形沒有顯示出來。此時，開始檢查繪制代碼的實現，看看是否有錯誤或遺漏。
在這里插入圖片描述

繪制的比例似乎是錯的

在調試過程中，發現幀條比例計算的結果有些異常，尤其是幀條的比例看起來不合理，遠低于之前所見的值。為了找出原因，決定進一步檢查問題所在。考慮到可能是因為在調試模式下執行時，代碼行為有所不同，或者是在處理的第一幀時數據才是合理的，因此需要仔細回顧和確認計算過程中每個步驟的輸出值。

此外，排除了調試時使用的時間代碼不正確的可能性，但仍不確定具體的原因，所以決定繼續深入分析，查看相關的變量和數據，以找出問題的根本原因。
在這里插入圖片描述

在這里插入圖片描述

讓我們暫時硬編碼FrameBarScale，以便調試

為了排除幀條比例計算的問題，決定暫時將其設置為一個硬編碼的值，例如5000萬個時鐘周期。這樣做是為了確保當前的問題不是由幀條比例計算引起的。考慮到如果假設每秒30幀且使用2GHz的機器，計算出來的周期數接近6000萬個，因此50百萬的值是合理的。通過設置該值為一個已知常數，可以暫時避免與比例計算相關的潛在問題，并將這個問題留待稍后處理，集中精力解決其他問題。
在這里插入圖片描述

在這里插入圖片描述

先注釋掉
在這里插入圖片描述

在這里插入圖片描述

調試可視化仍然沒有正確顯示

在檢查時發現，雖然有一些值出現，但它們只是很小的波動。我們逐步跟蹤了繪制過程，檢查了每個區域的最小Y值和最大Y值，結果它們幾乎相等，說明時鐘值太小，未能占據實際的空間。接著我們發現這些值并沒有預期的那樣占用很多時間，這可能意味著計算的周期數不正確，應該考慮到外部周期的總量，但實際值遠低于預期。

此外，還注意到有64個區域在開關，這顯得不太合理，因為在單個幀中，不可能有那么多區域頻繁開關。可能在所有線程之間有一些不同的表現，但也不太可能單個線程內會有這么多區域。通過進一步的檢查，發現打開的時鐘和事件時鐘之間的差值是合理的，但問題可能出在幀條比例計算上，這仍然是一個未知的因素。

整體來看，雖然時鐘的計算是正確的，但仍需要進一步排查為什么會出現這樣的問題，可能涉及到幀條比例或區域數量的計算錯誤。

我們沒有將縮放因子乘以圖表的高度

在檢查過程中，發現缺少了一個乘以高度的步驟，導致比例因子沒有正確計算。實際上，這個問題可能是因為我們沒有將比例值乘以條形圖的高度，導致結果不正確。這看起來像是一個疏忽所致，可能只是一個小的錯誤。

盡管如此，經過修復后，結果仍然不合理。預期是每個幀應該都有一個條形圖，但實際上我們沒有看到每個幀的條形圖，這表明當前的實現存在問題，未能正確繪制每個幀的條形圖。需要進一步排查并解決這個問題，才能確保每個幀都有對應的條形圖顯示。
在這里插入圖片描述

在這里插入圖片描述

是否還會有調試資產內存塊的可視化？

希望能像處理時間一樣，加入對內存的調試可視化。目標不僅是展示資產內存塊，還包括其他類型的內存塊。這樣做可以幫助更全面地理解和追蹤內存的使用情況，從而更好地優化和調試程序。

能否做一期關于項目管理、外包、自由職業招聘等的迷你劇集？編程很棒，但做游戲需要更多的東西。如果沒有的話，能否指向一些相關的好資源？

游戲開發不僅僅是編程，它涉及到更廣泛的項目管理和外包協調。對于大型游戲項目，尤其是有多個團隊合作時，正確的項目管理至關重要。除了技術人員外，還需要涉及設計師、藝術家、音效工程師等各方面的專業人才，甚至可能需要外包一些任務來提高效率。正確的管理和協調這些資源是成功的關鍵。

在項目管理方面，需要考慮的事項包括：

團隊協調和溝通：確保不同部門之間的順暢溝通，避免信息孤島。
任務分配：根據每個團隊成員或外包方的專長，合理分配任務。
預算和時間管理：合理規劃時間表和預算，確保項目按時交付且成本可控。
質量控制：確保外包的工作符合質量標準，并進行嚴格的測試。
外包管理：選擇合適的外包公司或自由職業者，建立清晰的合同和項目目標，避免后期糾紛。

此外，如果你想深入了解項目管理和外包的細節，以下資源可能會對你有幫助：

書籍：例如《Scrum敏捷項目管理》以及《游戲設計與開發管理》。
網站和博客：像Gamasutra（現稱GameDev.net）提供了大量關于游戲開發、項目管理和外包的文章。
課程：在線平臺如Coursera、Udemy、LinkedIn Learning等都有相關的項目管理課程。

這些資源可以幫助你更好地理解項目管理和外包的技巧，提升整個團隊的協作效率和項目的成功率。

在編寫實用工具或元程序時，是否使用與HMH相同的內存模型，還是直接malloc，反正程序運行一次，做完事情后就關閉？

在編寫工具或元編程時，是否會使用內存分配（如 malloc）以及這是否會產生問題，取決于元編程的具體方式。元編程的目標是利用模板或類似技術帶來的優勢，但避免它們所帶來的繁瑣和冗余。通過元編程，可以在代碼中直接實現所需的數據結構和內存分配系統，比如 AVL 樹、哈希表、內存分配器、引用計數分配器，甚至垃圾回收機制等。

在元編程中，通過某些技術（例如模板、宏或更高級的元編程系統），可以在編譯時自動生成所需的代碼，這樣就避免了運行時的重復計算，提升了效率。與手寫代碼的方式不同，元編程讓開發者可以抽象出復雜的內存管理和數據結構實現，而不必擔心代碼的冗長和復雜性。程序員只需要定義所需的行為，剩下的部分可以由編譯器或元編程系統自動處理。

不過，這并不是說所有元編程技術都是理想的。例如，C++的模板系統被認為是一個不太理想的元編程系統，主要因為它設計得不夠靈活和高效。模板雖然可以幫助程序員在編譯時生成代碼，但它的實現方式往往導致程序結構復雜，編譯時間長，且容易出錯。因此，雖然元編程的目標是實現更簡潔高效的代碼，現有的編程語言（如C++）并沒有提供完全理想的元編程工具。

綜上所述，元編程的關鍵是選擇合適的工具，根據需要的功能來決定使用哪種內存分配策略，而不必擔心實現的復雜度。元編程最大的優勢是能在編譯階段就生成代碼，避免了運行時的性能開銷，這也是理想的編程方式。然而，現有的編程語言常常沒有足夠好的支持，使得程序員不得不手動編寫大量冗余的代碼。

實時查看調試信息和事后查看日志信息的利弊是什么？

實時查看調試信息與將其記錄后再查看各有優缺點，主要取決于開發環境和需求。以下是這兩種方式的優缺點分析：

實時查看調試信息的優點：

速度：實時查看調試信息可以立即捕捉和反饋程序的狀態，不需要等到運行結束或暫停后查看日志。這對于需要快速響應和實時調試的情況非常有用，因為可以立即看到程序執行中的問題。
開發者的便利性：在一些開發場景中，可能會有多臺機器參與開發過程，比如開發游戲時，開發人員的工作站可能和實際運行游戲的設備（如游戲機）分開。實時調試允許通過網絡將調試信息從目標平臺傳輸到開發機器上，在開發機器上以直觀的方式查看調試信息。這避免了在開發機和目標設備之間來回切換的問題，尤其是在沒有足夠輸入設備（如鼠標和鍵盤）的情況下。

實時查看調試信息的缺點：

性能開銷：實時查看調試信息可能會影響程序的性能，因為在運行時需要頻繁輸出大量的調試數據。尤其是在處理大量數據或復雜的計算時，可能會占用過多的幀時間，導致性能下降。
調試信息過多：如果沒有良好的管理，實時輸出過多的調試信息可能使得關鍵數據被淹沒，導致信息過載，難以從中找出有用的內容。

記錄調試信息并后續查看的優點：

歷史分析：將調試信息保存到磁盤后，可以在程序運行后進行分析。通過查看不同時間點的日志數據，開發人員可以分析程序的歷史行為，找出問題的根源。例如，可以對比不同版本的日志數據，看看問題是否出現在某個特定的版本或運行階段。
數據持久化：保存的日志信息不僅可以幫助開發人員在當前版本中排查問題，還可以作為長期跟蹤和優化的依據。在未來的調試過程中，開發人員可以查找以前的日志數據，比較不同時間段的數據，找出趨勢或潛在的問題。

記錄調試信息并后續查看的缺點：

實時性差：保存調試信息后，開發人員需要等待程序運行完畢或達到某個特定條件才能查看日志，無法立即看到調試信息。這意味著問題可能需要一些時間才能被發現，適用于那些不需要立即響應的調試場景，但不適合快速調試和實時反饋。
日志管理：如果不對日志數據進行有效管理，日志文件可能會迅速增大，增加存儲負擔，查找有用信息也可能變得非常困難。此外，處理和分析大量的日志數據也需要額外的工具和時間。

總結：

實時查看調試信息適合需要即時反饋的場景，尤其是在開發過程中與硬件設備分離的情況下。它可以提高開發效率，但可能帶來性能負擔和信息過載。
記錄調試信息并后續查看適合需要長時間跟蹤、分析和比較的場景，特別是在較大的團隊和項目中。它可以幫助發現長期潛在的問題，但犧牲了實時性，并且需要更強的日志管理能力。

選擇哪種方式取決于開發環境、團隊規模以及調試的具體需求。如果是在小型項目中進行開發，實時調試可能更有優勢。而在大型項目或復雜環境下，記錄日志進行后續分析則可能更為重要。

非常感謝你提到cmirror。它直接解決了我很多問題，而且更容易理解。GetToken是為什么寫的？是配置文件嗎？似乎不是用在C代碼中的

提到的“get token”是用于配置文件的處理。它主要是處理類似于foo = string, number;這樣的配置表達式。配置文件通常由一些鍵值對組成，格式通常是鍵 = 值，其中值可以是字符串、數字等，多個配置項用逗號分隔，每項以分號結束。這些配置文件中的內容可以通過類似get token的機制來解析。

這些配置文件的處理并不像編程語言中的函數調用或復雜的表達式計算。它們主要關注的是讀取和解析配置文件中的簡單表達式，而不是執行函數或類似的復雜操作。因此，get token的功能并不涉及復雜的編程邏輯，而是關注于提取配置文件中的信息并將其轉換為可以理解和使用的格式。

當你發布時，你如何調試OpenGL/Direct3D相關的問題？

調試OpenGL或Direct3D等GPU相關的代碼非常復雜。當前并沒有使用OpenGL或Direct3D，討論的是如果將來使用這些技術時，如何調試它們。

調試GPU代碼通常非常困難，主要原因是GPU不像CPU那樣提供便捷的調試支持。GPU的調試方式常常是臨時的、無序的。常見的方法是使用一些專門的調試工具，但這些工具并不總是有效。例如，可能會用到一些工具如pics、insight debugger、Grem ADIZ、Valve為Linux開發的GL trace等。這些工具有時能提供幫助，但往往調試GPU代碼依然非常麻煩，特別是無法像在CPU中那樣逐步跟蹤代碼執行。

調試GPU代碼時，有時只能通過“試驗”來排查問題。舉個例子，你可以設置一些測試條件，并驗證是否能看到預期的結果。如果預期的結果沒有出現，那么就說明代碼中的某個部分沒有按預期工作。調試GPU代碼的一個主要問題是，無法像調試CPU代碼那樣逐行執行代碼，這使得問題排查非常困難。

在某些情況下，可以使用一些平臺特定的工具，這些工具由硬件廠商或第三方提供，能夠幫助開發者進行一些基本的調試。盡管這些工具有時能提供某些信息，但它們并不能完全解決所有問題。總的來說，調試GPU代碼比調試CPU代碼要復雜得多，且沒有像CPU調試那樣精細的控制，因此開發人員往往需要采用更傳統、更笨拙的方式來進行調試，甚至有時需要靠經驗和猜測來找出問題。