1

堅実な例から始めましょう。ハッシュ (32 ビット整数) を生成して localStorage に保存する関数があります。これは、一般的な通知に「次回から表示しない」機能を実装するためのものです。ハッシュがリストにある場合は、通知を表示しません。

このソリューションのコーディングを初めて試みた後、localStorage エントリは次のようになりました。

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

19 個のハッシュ、210 バイトのデータ。

しばらくして、コードを見直しました。整数を 10 進文字列としてダンプするだけでなく、実際のバイナリ データに変換しました。つまり、各ハッシュは、整数のバイナリ値を表す長さ 4 文字の文字列になります。私の localStorage エントリは次のようになります。

$ÄNð/tµ¹2BëCGÓ§X eµZì`"dhõÕqÂ7z¥Ðￌq¤ﾹT!ºￎ4ÈￃZ2R￞¥½O"3äò￀Cæc マ/=

19 個のハッシュ、76 バイトのデータ(印刷できない文字が含まれています)

これは 63.8% の節約です。

さて、localStorage がデフォルトで 5MB のストレージ容量を提供することは十分承知しています。最初の方法で何万ものハッシュを簡単に保存できましたが、まったく問題はありませんでした。しかし、私は効率的であることが好きです。同じデータを 1.8MB で保持できる場合 (上記と同じ圧縮率)、自分のコンピューターに 5MB のファイルを置きたくありません。そのため、可能であればすべての PNG をインデックス付きパレットとして保存しています。

これは良いメンタリティですか？それとも私はただ衒学的ですか？この質問は次のように要約できると思います:圧縮する必要がありますか?それとも、必要以上のリソースがあるために気にしないでください?

4

1 に答える 1

1

コードに来るときはペダンティックが良いです。可能な場合は圧縮しますが、コードを読むときに、ハッシュが何らかの方法で保持されていることを読みやすく理解できるようにしてください。

私が言いたいのは、効率のためにコードの可読性と保守性を犠牲にしないということです。

于 2012-06-22T20:50:33.623 に答える