繁體中文

新功能

報告載入不再苦等,重複點擊瞬間顯示

現在當你連續點擊查看「今天」或「七日」的 HTML 報告時,畫面會瞬間跳出,不再每次都讓你苦等轉圈圈。以前只要你點開報告,程式就會把所有的 Antigravity 對話資料庫、Codex 的 OTel 追蹤紀錄(OTel trace log,記錄軟體執行步驟的流水帳)從頭到尾重新打開解析一次;甚至在產生同一份報告的過程中,同一個本地日期和工作目錄對應的專案名稱,也會被重複計算好幾次。現在這三個地方都補上了對應的快取(cache,把算好的結果暫存起來,下次直接拿來用的機制)——針對 SQLite(一種輕量級資料庫)來源採用檔案層級暫存,而單次報告內的重複運算則用當次的記憶體暫存。因此,當你第二次點擊同一個區間時速度會大幅提升,而顯示的數字結果完全不受影響。這就像是一間餐廳的結帳櫃台,以前每印一次明細,店員都要跑進廚房重看一次點菜單、重新按一次計算機;現在店員懂得把剛算好的總金額寫在便條紙上,你再要一次同一桌的帳單,他看一眼便條就能立刻給你。

English

FEATURE

Reports load instantly on repeat clicks without redundant processing

When you repeatedly click to view the "Today" or "Last 7 days" HTML report, it now pops up instantly instead of making you wait. Previously, every time you opened the report, the program would re-open and re-parse all your Antigravity conversation databases and Codex's OTel trace log (a detailed diary of every step the software took) completely from scratch. It would even repeatedly recalculate the same local dates and working directory mappings during a single report generation. Now, appropriate caches (a mechanism that temporarily stores calculated results to be reused later) have been added to all three areas. It uses file-level caching for the SQLite (a lightweight database) sources, and in-memory caching for repeated calculations within a single report build. As a result, clicking the same time period a second time is dramatically faster, with no change to the final numbers. It's like a restaurant cashier who used to run back into the kitchen to recount the order tickets and punch the calculator all over again every time you asked for a receipt duplicate; now, they just write the subtotal on a sticky note, so if you ask for the same bill again, they can hand it to you in a split second.

原始 CHANGELOG

Original changelog報告載入不再苦等,重複點擊瞬間顯示
**Report generation is much faster, especially on repeat clicks**: generating the "Today"/"Last 7 days" HTML report used to re-open and re-parse every Antigravity conversation database and re-scan Codex's OTel trace log from scratch every time, and recomputed the same entry's local date and working-directory-to-project-name mapping repeatedly within a single report build. All three now cache appropriately (file-level caching for the SQLite sources, in-memory caching scoped to each report build), so a repeat click of the same period is dramatically faster with no change in the numbers shown.