壓縮localStorage有用嗎？

Question

我會與固體例如開始：我有生成散列（32位整數），並在localStorage的保存它們的功能。這是爲了實現常見通知的「不再顯示我」功能：如果散列在列表中，則不顯示通知。

我在編寫此解決方案的第一次嘗試後，我進入的localStorage是這樣的：

616845040,796177849,848184043,1133088406,1205053317,1478518197,1525440546,1686606993,1753347541,1908577591,2056496592，-864967541 ，-1185668678，-835401591，-1017499054，-559563441，-1842092814，-1069291933，-1887162563

19哈希，210個字節的數據。

過了一會兒，我重新審視代碼。我將它們轉換爲實際的二進制數據，而不是將整數轉換爲十進制字符串。換句話說，每個散列現在是一個由四個字符組成的字符串，代表整數的二進制值。我localStorage的入門現在看起來是這樣的：

$和/tμ¹2BëCGÓ§XeμZì`「dhõÕqÂ7z¥dㅗq¤ㅉ牛逼ºㅙ4EㅐZ2R￞¥½Oメ3AO￀CAECマ/ =

19散列，76個字節的數據的（那裏面有一些非打印字符）

這是63.8％的儲蓄。

現在，我清楚地意識到，localStorage的提供，默認情況下， 5MB的存儲空間使用第一種方法很容易存儲數以萬計的哈希值，完全沒有問題。但我喜歡高效。當我有1.8MB的相同數據（相同的壓縮比率）時，我當然不希望我的電腦上有5MB的文件。這就是爲什麼我儘可能將所有PNG保存爲索引調色板的原因。

這是一個良好的心態呢？還是我只是迂腐？我想這個問題可以概括爲：我應該壓縮，還是隻是不在乎，因爲有更多的資源比我將永遠需要？來代碼時

Answer 1

迂腐還是不錯的。儘可能壓縮，但請確保在閱讀代碼時，仍然可以閱讀並理解哈希以任何方式保存。

我的意思是，不要犧牲代碼的可讀性和可維護性的效率。