https://asobinet.com/info-discon-ef-m-soon/
EF-Mマウント終了のお知らせ
つーかまずtargetSdkVersion上げて試験リリースを出すべきか
諸事情で俺のメイン機はSonyやサムスンなので、Android 12の使用経験は不足ぎみ
ゆる募： #SubwayTooter の#Android 12 での不具合情報
今朝 Store MI で遊んだやつを表にしたよ。
1GBデータでテストしたのでRead は 2GB Ram Cache の影響が支配的。
WriteはだいたいSSDの速度に依存するけど、バスが忙しくなるランダムアクセスだと素のSSDよりやや低下する印象。
Optaneのランダムアクセスに強い特徴は出なかったけど、素の状態のランダムライトでもCrucial P1 500GB の方が勝ってるので、StoreMIの影響ではなさそう…？Intelマザボだと異なる結果になるかもだけど。
ではPCIe 4.0 x4 のSSDをキャッシュに使うとどうか。…Optaneより速いやん。STのリビルドは31秒だった。
というか、OSのディスクキャッシュが多ければそれで充分なんじゃないか説まである。キャッシュの上にほぼ同速か遅いキャッシュを重ねても、あまり利点はないだろう。トラブルが増えるだけ損だ。
この状態でSTのリビルドを数回試したが、うちのCドライブ(PCIe 4.0x4)が21秒のところ、Store MIで組んだドライブは42秒だった。HDDよりは全然早いと思うが、最近のSSDよりは倍程度遅い。
Store MIで HDD + Optane 32GB + 2GB RAM Cache を組んだ時のベンチ。PCIe 3.0 x2 接続のせいか、ザコSSDより書き込みが遅くなってる。
RAMキャッシュを無効にしても、シングルドライブ仮想Tierである限りはパフォーマンスは元には戻らないようだ。
この状態からStore MI で move all data to slow media するとデータは消えずにHDD部分がSingle Driveの仮想Tierになり、そして再度RAMキャッシュを追加すると… RAMキャッシュが効くのだ。画像はこの状態のHDDとStore MI 追加前のHDDのベンチ。書き込みは遅くなるが、ランダムリードは速くなる。
チャットルーム的な使い方する人ばっかりになるとそれはそれでバランス悪いという話だね
ぁー、だめだ。AmazonDriveの同期が終わるまではじっとしていよう…
ゼロ幅スペース（ゼロはばスペース、ZWSP: zero width space）は、コンピュータの組版に用いられる非表示文字で、文書処理システムに対して語の切れ目を示すのに用いる。
画像があればカスタム絵文字にするけど、もうこのeagleの画像をまんまつかってhawkで登録すればいいんじゃないかな。。
Lightroomという名前のアプリはアップデートで別のものを指すようになった。画像を一枚開くたびにダウンロードで待たされるのはさすがに耐えられないのでClassicの方を使うかなあ…
