Canon CR2 –> .JPEG 速度加倍.. 該換 Core2 Quad 了嘛?
摘要提示
- 效能瓶頸: 歸檔程式的速度卡在 Canon Codec 的 CR2 轉 JPG 步驟。
- 多執行緒限制: 同一個 process 中的 Canon Codec 無法重入，無法同時用到多顆 CPU。
- 方案構想: 以多個獨立 process 並行轉檔，繞開單一 process 的重入限制。
- 驗證結果: 同時執行兩個轉檔程式，CPU 使用率可達約 80%，單程式速度不降。
- 實作方式: 將轉檔邏輯抽成獨立 .exe，由主程式同時啟動兩個轉檔程序。
- 效能提升: 單檔仍需 70 秒，但可在同時間完成兩檔，等效速度倍增。
- IPC 顧慮: 雖然跨程序溝通麻煩（參數、回傳、解析），但不耗大量運算資源。
- 成本效益: 面對大量照片（動輒上百張），多 process 的複雜度換得實質效能。
- CPU 利用: 從單程式受限到多程序併行，有效提高 CPU 使用率。
- 升級動機: 效能解法成功後，考慮升級至 Q9450（四核心）以進一步擴充併行度。
全文重點
作者在開發影像歸檔程式時，發現整體效能被 CR2 轉 JPG 的步驟嚴重拖累，主要瓶頸在 Canon Codec 上。即便透過 ThreadPool 將可併行任務盡量堆疊，提高 CPU 利用率，最後仍因轉檔步驟無法並行而受限。關鍵問題在於 Canon Codec 在單一 process 內存在「不可重入」的限制，導致無法同時在多核心上運作。作者於是嘗試以兩個相互獨立的 process 並行轉檔，假設多數安全機制只鎖在 process 內部，不做跨 process 的全域鎖。以簡單測試程式驗證後，結果顯示同時啟動兩個轉檔程序可讓 CPU 使用率飆至約 80%，且單個轉檔程序的速度並未下降。於是正式將轉檔邏輯抽成獨立 .exe，讓主程式同時啟動兩個轉檔工作。這樣雖然單檔仍需 70 秒，但 70 秒後可同時完成兩張，等效速度加倍。作者原先抗拒此法，因為 IPC（跨程序溝通）在參數傳遞、回傳值、檔案/arguments 解析等方面較麻煩；然而這些作業不耗大量運算，對比每張圖需 70 秒且常見大量批次的需求，權衡後仍非常划算。最終他幽默地表示，既然並行有效，是否該考慮升級到四核心 Q9450，讓效能再上層樓。
段落重點
換四核心的時機感
作者開場直言有換四核心 CPU 的衝動，因為實務上轉檔性能已成瓶頸，期待更高併行度能改善整體速度。
真正的瓶頸：Canon Codec 的不可重入
雖然用 ThreadPool 將可獨立的工作並行化，但最後卡在 CR2 轉 JPG。Canon Codec 在單一 process 內無法重入，導致多執行緒也無法同時吃滿多核心，整體效能被最慢的一段拉低。
假設與驗證：用多 process 繞過限制
作者提出用兩個獨立 process 並行的構想，基於常見安全設計僅在 process 內鎖定資源。先寫小工具測試，同時跑兩份轉檔，CPU 使用率約 80%，單份速度未衰減，驗證可行。
正式實作：抽轉檔為 .exe 並雙工啟動
將轉檔邏輯抽離為獨立執行檔，由主程式同時啟動兩個轉檔程序。實測單檔仍需 70 秒，但兩檔可同時完成，等效速度翻倍，整體吞吐量大幅改善。
IPC 的取捨與成本效益
作者坦言先前不想碰 IPC，因為參數、回傳與資料解析都麻煩。然而這些是低運算成本工作，面對動輒上百張、單張 70 秒的批次場景，其複雜度換來的效能回報極高，權衡後值得。
展望與升級考量
既然多 process 可有效提升 CPU 利用率與吞吐，作者打趣地考慮升級至 Q9450 四核心，期望能以更多平行程序把硬體資源榨乾，進一步縮短整體轉檔時間。
資訊整理
知識架構圖
- 前置知識
- 影像檔格式與轉檔流程：Canon CR2（RAW）與 JPEG 的差異與轉換步驟
- 作業系統與程式設計基礎：process、thread、CPU 核心、I/O
- 同步機制概念：lock、不可重入（non-reentrant）、臨界區
- .NET 基礎：ThreadPool、啟動外部程序、參數傳遞
- 核心概念（及其關係）
- 轉檔效能瓶頸：Canon Codec 在單一 process 內不可重入導致多執行緒無效
- 多程序並行：以多個 process 規避 per-process 鎖，提升多核心利用率
- IPC 成本評估：雖麻煩但非計算密集，對長時轉檔工作而言成本可忽略
- 吞吐量與延遲：單檔延遲不變（70 秒），並行增加吞吐量（兩檔 70 秒完成）
- 架構調整：將轉檔抽離為獨立 exe，由主程式協調與監控 關係：瓶頸辨識 → 多程序策略 → 架構抽象（拆成 exe）→ IPC/參數傳遞 → 吞吐量提升
- 技術依賴
- Canon Codec（第三方編解碼器，具 per-process 不可重入限制）
- .NET 執行環境：ThreadPool（先前嘗試）、Process 啟動與管理、引數/檔案傳遞
- 作業系統多核心排程：允許多進程在不同核心上並行
- 檔案系統：用於參數/結果傳遞與中介狀態
- 應用場景
- 大量 RAW→JPEG 批次轉檔工具
- 任何受限於第三方庫在單一 process 不可重入的批處理作業（如影音轉檔、壓縮/解壓）
- 需要提升 CPU 利用率、並將長時任務並行化的資料處理流水線
- 舊程式碼或黑盒 SDK 無法修改、必須以系統層面並行規避限制的情境
學習路徑建議
- 入門者路徑
- 了解 CR2 與 JPEG 基礎、轉檔意義與流程
- 學會辨識效能瓶頸（觀察 CPU 利用率、單步測量）
- 嘗試使用單一 process + ThreadPool，理解不可重入帶來的限制
- 進階者路徑
- 學習多程序架構：如何以主控程式啟動多個轉檔子程序
- 熟悉參數傳遞與結果收集：命令列引數、檔案/資料夾協定、退出碼
- 建立可靠的併發控制：同時進程數、排程、失敗重試、日誌
- 實戰路徑
- 抽離轉檔邏輯為獨立 exe，主程式負責分派工作與監控
- 在雙核/四核機器上測試進程數與 CPU 利用率，尋找最佳並行度
- 加入故障處理（逾時、崩潰）、資源管理（I/O/磁碟爭用）、最終吞吐量驗證
關鍵要點清單
- 瓶頸辨識：效能卡在 Canon Codec 的不可重入，而非主程式邏輯或 ThreadPool (優先級: 高)
- 多執行緒的侷限：在不可重入的單一 process 環境中，多執行緒無法提升吞吐量 (優先級: 高)
- 多程序解法：以多個獨立 process 規避 per-process 鎖，讓多核心真正並行 (優先級: 高)
- 吞吐量提升：單檔時間不變，但並行可在相同時間完成多檔，實測約翻倍 (優先級: 高)
- CPU 利用率觀測：兩個進程可將 CPU 使用率由低提升至約 80%（依機器而異） (優先級: 中)
- 架構拆分：將轉檔功能抽成獨立 exe，主程式負責協調與調度 (優先級: 高)
- IPC 成本評估：雖麻煩（參數、回傳值、解析），但相對長時轉檔成本極低 (優先級: 中)
- 參數傳遞策略：使用命令列引數或檔案協定約定，簡化跨程序溝通 (優先級: 中)
- 結果回傳與監控：退出碼、狀態檔、日誌以回報成功/失敗與錯誤資訊 (優先級: 中)
- 併發度控制：依 CPU 核心與 I/O 能力設定同時進程數，避免過度競爭 (優先級: 高)
- 資源爭用管理：注意磁碟 I/O、記憶體與快取壓力，避免併發過多反而變慢 (優先級: 中)
- 容錯與重試：子程序失敗的重試策略與隔離，提升整體穩定度 (優先級: 中)
- 可擴展性：由雙核擴展至四核（如 Q9450），理論上可接近線性提升 (優先級: 中)
- 測試與驗證：以小批量驗證正確性與效率，再擴大到大量資料 (優先級: 高)
- 第三方庫限制意識：當無法修改黑盒庫時，用系統層級（process）策略繞過 (優先級: 高)
