*
這是為了上次我的Firefox3瘋狂Live Bookmark測試後, 等待(win版)3.0.1釋出後立即再做的的測試
- 與上次條件完全一樣, 重開新的profile, 同樣的書籤備份檔, 同樣的測試流程
廢話不多說, 看圖說故事...
這是更新到3.0.1後啟動的畫面
因為有多個分頁的關係(記憶體會增加)所以先關掉再啟動一次, 靜置後確定記憶體狀況變化, 與上次結果相同
準備restore書籤檔 - 就是使用上次的完全一樣的備份檔, 217個rss書籤
上次restore開始後用了兩分鐘才出現資料夾(進度一半), 這次不同幾乎是馬上出現. 不過記憶體的情況跟上次也一樣會大幅上升, 峰值也是略衝過200M, 不過...
...兩分鐘內就完成了, 原本上次的測試記憶體會有兩次大幅下降後又上升這樣起伏的情況, 這次顯然沒有, 一次到峰值後就下降直到cpu為0. 我大概可以肯定匯入的動作比起上次節省一半的時間
不過待數分鐘記憶體回降後還是比乾淨狀態下大了一倍(我反覆測試結果我想可能比上次測試大了一點).
跟上次一樣, restore完後將Fx3重開, 再靜置看看. 這次的情況有點奇妙, 上次靜置下會有幾乎固定的每分鐘發生一次動作(就是數秒鐘的檢查更新)的情況, 但這次我反覆測試至少四次, 只有一次會有較頻繁的動作 - 說較頻繁其實也隔了兩三分鐘. 其他的重複測試, 等待數分鐘都幾乎感覺不到...所以我上次連續放四張這次只放了兩張(不然不知道會花多少時間在等待上). 這次不但動作難察覺, 發生時cpu的使用量也很低(別忘了我的"配備"是很差的...). 3.0.1版似乎是把書籤的更新動作做了相當的調整.
準備要將所有即時書籤刪除
也是兩分鐘左右就完成, 不過記憶體與上次相同上升了十幾M, 不過我想記憶體的增加這部份應該是可忽略的, 這也許是因為有開組織書籤視窗的關係
跟上次有點不同的是, 刪除書籤的速度雖然縮短, 卻比還原時似乎還長一點, 反覆測試結果也一樣
這現象有點奇怪就是, 通常這類刪除的動作應該會明顯的比增加資料時更短才對, 不知道是不是操作資料庫動作的關係使然. 個人感覺是應該有再改進的空間
----
上次測完的感想寫了不少, 這次我想可以簡單的說就夠了 : 簡言之是個雖不至完美卻已經相當明顯有效的改進. 3.0.1本身做的調整加上新版Sqlite(0.5.9)元件的使用足夠消除大半上一版非常糟糕的cpu與i/o問題.
不過因為記憶體的情況的關係, 個人是建議如果還原或是更動刪除大量書籤後, 最好是重啟動一次. 這一點若能改進更好 (不過個人感覺上這問題不至於嚴重至影響操作, 畢竟沒多少人書籤的數量這麼大, 所以觀察情況後看不出明顯的差別這一點就可忽略了.
總之個人可肯定這一版的表現明顯會比上次好, 當然也建議3.0版的使用者務必要更新, 3.0.1不只是有places的改進還修正了上次釋出後幾乎馬上發現的安全漏洞.
-
這兩次的測試結果都僅供參考, 個人不保證所有使用者的3.0.1會與我有相同的結果. 同樣的後段感想也純屬個人的看法, 如果有任何說法等錯誤請見諒並給予指教.
