透過批次讀寫資料來加快 Calc 巨集的運行速度

對於運行緩慢的 Calc 巨集來說，最可靠的加速方法是用一次區域讀取、一次記憶體循環和一次區域寫入來取代重複的逐單元格讀寫操作。這減少了 Basic 和 Calc 之間的呼叫次數；但並不能保證速度的固定提升，因為公式、格式設定、檔案大小和巨集邏輯也會影響運行時間。下面的範例更改了狀態列，並展示如何衡量速度和正確性。 API 細節已於 2026 年 10 月 9 日根據 LibreOffice 26.8 文件進行核對。

哪些方面需要改進？如何衡量改進效果？

在工作簿副本上執行目前巨集，並記錄其運行時間。對於舊宏和修改後的巨集，請使用具有相同初始資料的新副本，或在運行之間恢復輸入；否則，第二次運行可能效率較低。保持行數、計算設定和輸出條件相同。重複每次運行並比較典型時間，而不是依賴一次異常快速的運行結果。檢查結果是否符合預期規則。如果巨集運行時間更短，但更改了錯誤的行，則不算改進。

LibreOffice Basic 的Timer計時器函數會報告自午夜以來的秒數；將其賦值給Long變數即可獲得數值形式的秒數。對於較短的運行時間，記錄起始值和結束值並相減。如果結束值較小，則表示運行時間已超過午夜，因此需將差值加上 86,400 秒。計時器會報告整數秒數；ScriptForge如需毫秒精度，請使用計時器服務。請參閱LibreOffice Basic 計時器文件和ScriptForge 計時器服務文件。除非工作簿的開啟、儲存和手動檢查是實際任務的一部分，否則請將這些操作放在測量時間間隔之外。

包含 ID、區域和狀態列以及選定資料範圍的 Calc 工作表 — 每次計時運作都使用相同的連續資料範圍和工作簿條件。

為什麼大型 Calc 宏會變慢？

循環重複呼叫getCellByPosition()或讀取/寫入單一單元格屬性，會導致 Calc 每次操作都透過 Basic 到 Calc 的介面進行互動。如果行和列很多，即使轉換本身很簡單，這些呼叫也會累積起來。循環遍歷記憶體數組雖然也會存取每一行，但可以避免為每個值單獨呼叫單元格 API。

先移除那些不會影響結果的操作：避免在循環內選擇或啟動單元格，如果一次區域操作就能解決問題，就不要重複計算或格式化單元格，如果只需要處理一個有限的資料塊，就不要處理整列。這些變更有助於在添加更多控制項之前找出真正的瓶頸所在。

如何將一個範圍作為數組處理？

使用一個僅包含巨集要變更的值的矩形區域。範例假設工作表名為 `<workbook_name>` Data，第 1 行包含標題行，C 列包含狀態值。請將工作表名稱和區域變更為與您的工作簿相符的名稱和區域。 API 會將getDataArray()區域作為包含值的行傳回；setDataArray()並將相同大小的陣列寫回該區域。

LibreOffice Basic 編輯器使用 getDataArray 將選定的 Calc 區域讀取到 aData 中 — 在記憶體循環之前，讀取一次所需的矩形區域。

Sub UpdateStatuses
    Dim oSheet As Object
    Dim oRange As Object
    Dim aData As Variant
    Dim i As Long

    oSheet = ThisComponent.Sheets.getByName("Data")
    oRange = oSheet.getCellRangeByName("A2:C10001")
    aData = oRange.getDataArray()

    For i = LBound(aData) To UBound(aData)
        If aData(i)(2) = "pending" Then
            aData(i)(2) = "review"
        End If
    Next i

    oRange.setDataArray(aData)
End Sub

行數組從零開始：aData(i)(2)指向每行的第三列。這裡是 C 列，因為選定的區域從 A 列開始。數組的外層序列代表行，每個內層序列代表列。傳遞給 `XCellRangeData` 的範圍setDataArray()必須與陣列的維度相同；不符會引發錯誤。請參閱LibreOffice XCellRangeData API 參考和LibreOffice ScriptForge 陣列文件。

LibreOffice Basic 巨集會將記憶體數組中待審核的值進行更改，並將陣列寫回。 — 在記憶體中套用該規則，然後一次將完成的陣列寫入 Calc。

將公式單元格排除在僅值更新之外

getDataArray()傳回儲存格值時，會將其作為數字或字串傳回，而不是原始公式文字。如果您讀取包含公式的區域並使用該陣列寫回setDataArray()，則這些公式可能會被其目前結果取代。請將值數組方法限制在應包含值的輸入/輸出儲存格中。當巨集必須保留或修改公式時，請使用公式陣列方法getFormulaArray()，setFormulaArray()或僅處理非公式區域。 XCellRangeFormula API 參考文件中記錄了該獨立介面。

何時應該更改計算或顯示設定？

僅在測量數組版本後才測試這些選項。如果公式重新計算佔用大量運行時間，您可以查詢isAutomaticCalculationEnabled()並暫時停用自動計算enableAutomaticCalculation(False)，然後在需要時恢復原始設定並重新計算髒儲存格。將恢復操作放在清理路徑中，以避免錯誤導致工作簿進入手動計算模式。如果巨集需要在步驟之間使用最新的公式結果，請勿停用計算。 LibreOffice 會將calculate()重新計算髒單元格記錄為calculateAll()強制執行完全重新計算，這本身可能很耗時。請參閱XCalculatable API 參考。

lockControllers()當巨集修改多個儲存格時，可以暫停某些用於顯示更新的通知。每次鎖定都應與 `<lock>` 屬性綁定unlockControllers()，包括巨集透過錯誤處理程序退出時。這可以減少顯示更新的工作量；但它不會關閉公式計算，也不會將逐單元格邏輯轉換為批次操作。請將其用於螢幕刷新瓶頸，而不是替代範圍數組。請參閱XModel API 參考。

如何驗證變更並知道何時切換方法？

在工作簿副本上執行修改後的宏，並在與基準測試相同的條件下記錄其運行時間。比較受影響的行、未受影響的行、公式和關鍵總計。如果生產工作流程包含儲存步驟，請儲存、關閉並重新開啟副本；這可以發現快速目視檢查遺漏的問題。重複運轉後，性能應持續改進，且輸出檢查持續通過。

計算工作表顯示更新後的狀態值和一個空白的時間比較表 — 確認轉換後的數值並記錄測量時間，不要預先假設加速。

如果巨集仍然將大部分時間用於複雜的公式、格式設定、檔案 I/O 或排序，則應單獨分析該階段的效能；範圍陣列只能減少重複的儲存格存取。對於非常大的工作表，完整的記憶體數組也會佔用大量記憶體。如果記憶體壓力增大，可以一次處理幾列，或將行分成若干大小合適的區塊，同時檢查每個區塊是否在預期的行上開始和結束。如果資料已存在於資料庫中，且任務是篩選、分組或更新記錄，則將這些工作移至資料庫查詢可能比將每筆記錄載入到 Calc 中更合適。