亚洲在线久爱草,狠狠天天香蕉网,天天搞日日干久草,伊人亚洲日本欧美

為了賬號安全,請及時綁定郵箱和手機立即綁定
已解決430363個問題,去搜搜看,總會有你想問的

驗證 IndexedDB (Int8Array) 中存儲的數據的大小和類型

驗證 IndexedDB (Int8Array) 中存儲的數據的大小和類型

慕哥6287543 2023-06-29 15:41:26
我正在瀏覽器客戶端中設置一個基于 IndexedDB 的虛擬文件系統。我的假設是,將類型化數組存儲為值將是有效的;特別是,我通過 保存 8 kB 數據塊Int8Array。我必須用什么方法來驗證其有效性——實際使用的空間、實際的數據表示?例如,在 Chromium 中,我可以看到似乎Int8Array得到了正確的保存。但“清除存儲”頁面顯示的存儲大小高得令人懷疑 - 91 kB - 盡管我編寫的第一個測試文件大小僅為 40 kB(40096 字節分布在 5 個密鑰上,加上 24 字節用于元數據密鑰)。鍵是非常小的數組,包含短字符串路徑和數字。所以看起來存儲需要的時間大約是預期的兩倍:相比之下,我在 Firefox 中找不到有關使用量的任何信息,但存儲瀏覽器僅顯示值的“數組”類型,并且它們以 JSON 對象表示的效率非常低,盡管這可能只是顯示問題:ArrayBuffer一個相關的問題是,存儲對象與Int8Array查看對象之間有區別嗎?ArrayBuffer我嘗試了兩者,并且大小差異最小(如果我使用而不是作為傳遞給 IDB 的值,Chromium 使用 90.8 kB 而不是 90.9 kB Int8Array)。
查看完整描述

1 回答

?
慕哥9229398

TA貢獻1877條經驗 獲得超6個贊

第一:當然,只寫入一個小文件可能會扭曲圖像,因為數據庫本身的開銷會被打折。因此,我改為編寫了一個 40 MB 的文件(現在ArrayBuffer直接使用),現在 Chromium 報告的存儲使用量略低于 41 MB,確認數據存儲相對緊湊。事實上,我可以看到實時更新的存儲使用量在回到 41 MB 之前暫時較高,這表明也正在運行壓縮/清理算法。

由于 Firefox 無法顯示 的數據使用情況file://,我通過 Web 服務器運行它進行測試,這里也使用了 41 MB 的空間。


另一個令人驚訝的結果是,巧妙地存儲一個Int8Array數組實際上似乎也存儲了整個支持ArrayBuffer內容。因此,雖然這些值是Int8Array(8192)在 Chromium 中報告的,但由于底層ArrayBuffer大?。ㄔ谖业睦又袨?64K),存儲空間要大得多。從這個意義上說,最好直接存儲ArrayBuffer實例以避免意外。

順便說一句,在這項任務中,Firefox 的速度比 Chromium 快大約 3 倍。兩者的執行速度仍然非常慢(以 8 KB 為塊存儲 41 MB 的異步 I/O 分別需要 3 秒和 10 秒)。


查看完整回答
反對 回復 2023-06-29
  • 1 回答
  • 0 關注
  • 190 瀏覽
慕課專欄
更多

添加回答

舉報

0/150
提交
取消
微信客服

購課補貼
聯系客服咨詢優惠詳情

幫助反饋 APP下載

慕課網APP
您的移動學習伙伴

公眾號

掃描二維碼
關注慕課網微信公眾號