P4 Fusion 是一個使用 Perforce Helix Core C++ API 和 Libgit2 用 C++ 編寫的快速 Perforce 到 Git 的轉換工具，試圖緩解git-p4.py的性能瓶頸。

這個項目是作為一個內部項目的概念驗證開始的，它需要將P4倉庫轉換為Git倉庫。Git內部也有一個類似的解決方案，叫做git-p4.py。然而，它在處理任何超過1GB大小的倉庫時有性能問題，而且它使用Python2在單線程中運行，這給git-p4.py在更大的使用場景中的使用增加了一系列限制。

該工具通過以下方式解決了 git-p4.py 中一些最有影響的擴展和性能限制：

• 使用Helix Core C++ API來處理下載 CL，從而更好地控制內存以及如何將其提交到 Git 存儲庫，而無需進行不必要的內存復制和文件 I/O。
• 使用libgit2將從 Perforce 服務器接收到的文件內容按原樣轉發到 Git 存儲庫，同時盡可能避免內存復制。該庫允許從內存中簡單存在的文件內容創建提交。
• 使用在 C++11 中實現的自定義基于喚醒的線程池，該線程池運行 Helix Core C++ API 的線程本地庫上下文，以對變更列表下載過程進行大量多線程處理。

值得注意的是，P4 Fusion?的速度快到足以在你的Perforce服務器上瞬間產生巨大的負載（如果以中等數量的線程運行，在幾分鐘內超過15萬個請求）。因此，它需要仔細監測以確保Perforce服務器不受影響。這個工具將繼續產生負載，沒有任何速率限制（除了這個工具提供的運行時選項外），直到轉換過程完成。然而，沒有速率限制，用幾百個網絡線程（如果可能的話，甚至更多）來運行這個工具，是在轉換過程中實現最大速度的理想情況。

網絡線程的數量應設置為一般多于邏輯CPU的數量，因為最耗時的步驟是下載CL數據，這主要是網絡I/O的限制。

官方研究表明，這個工具的運行速度比 git-p4.py 快 100 倍以上。在一個包含約3393個中等規模變更列表的倉庫路徑內，使用 200 個并行連接進行歷史轉換的平均時間為 26 秒，而 git-p4.py 轉換同一倉庫路徑需要接近 42 分鐘。如果Perforce服務器有完整的文件緩存，那么這些轉換時間可能是可重復的，否則如果文件緩存是空的，那么前幾次運行預計會花費更多時間。

對于更大的倉庫（數百萬個 CL 或更多），這些執行時間預計會按預期擴展。該工具提供了在轉換過程中控制內存利用率的選項，因此這些選項將有助于更大的用例。

? ./build/p4-fusion/p4-fusion
[ PRINT @ Main:24 ] Running p4-fusion from: ./build/p4-fusion/p4-fusion
[ PRINT @ Main:43 ] Usage:
[Required] --port
        Specify which P4PORT to use.

[Required] --path
        P4 depot path to convert to a Git repo

[Required] --lookAhead
        How many CLs in the future, at most, shall we keep downloaded by the time it is to commit them?

[Required] --src
        Local relative source path with P4 code. Git repo will be created at this path. This path should be empty before running p4-fusion.

[Required] --client
        Name/path of the client workspace specification.

[Required] --user
        Specify which P4USER to use. Please ensure that the user is logged in.

[Optional, Default is false] --includeBinaries
        Do not discard binary files while downloading changelists.

[Optional, Default is false] --fsyncEnable
        Enable fsync() while writing objects to disk to ensure they get written to permanent storage immediately instead of being cached. This is to mitigate data loss in events of hardware failure.

[Optional, Default is 10] --retries
        Specify how many times a command should be retried before the process exits in a failure.

[Optional, Default is 16] --networkThreads
        Specify the number of threads in the threadpool for running network calls. Defaults to the number of logical CPUs.

[Optional, Default is -1] --maxChanges
        Specify the max number of changelists which should be processed in a single run. -1 signifies unlimited range.

[Optional, Default is 1] --printBatch
        Specify the p4 print batch size.

[Optional, Default is 100] --refresh
        Specify how many times a connection should be reused before it is refreshed.