/ddddddiary

仕事したりしていた。Web Audio API 詳しくなりたい。低調な日々が続いており、ぼんやりと過ごしてたけど、揺り戻しでしゃっきりする。溜まってた諸々を片付ける。

---

• NATE SMITH - ネイト・スミス｜ARTISTS｜BLUE NOTE TOKYO
  • 行きてえ

ふあ〜ここ数日ワタワタしていてな〜んにもできてない。特筆すべきことと言えば演劇見たことぐらい。良かった。ほとんど目の前ぐらいの距離で観劇したんだけど、その距離の近さも相まって、なんというか演劇固有の、演者がリアルな人間として眼の前に存在してることによる没入感みたいなものを始めて体感できたかもしれない。

---

• DHH Is Right About Everything - YouTube
  • ThePrimagen は向こうの Web 開発系のインフルエンサーで、HTMX の（超局地的な）流行の影の立役者。このヒゲのおじさんの動画を見てれば英語圏のトレンド、インターネットの雰囲気がどうなってるのか大体分かる（インターネットの雰囲気が分かるだけでなんか深い学びがあるわけではない、なぜならインターネットってそういうもんだから）のだが、最近は DHH に同調しているっぽい 。
  • ここ数年の DHH はとにかくサーバレスとかクラウドをやめて VPS もしくはベアメタルに回帰せよと連呼しており、VPS にデプロイするためのツール（Kamal）を作ったりしてる。実際にこれらマネージドサービスは高いので、純粋に料金だけ考えれば間違った選択ではないんだけど、PaaS の抽象化に去勢された大半の Web 開発者にとって DHH の推す方向はもう現実的ではない気もする。が、例によってネットで声のデカい人たちは逆張りが大好きであり、信奉者は増えつつある気がする。
  • leerob（Vercel の DevRel）が、Next.js をセルフホストするチュートリアルを公開したのも、この辺の流れに応えるものだと思われる（Next.js の開発を支えてるのは Vercel の収益であるはずなんで葛藤があっただろう）。
  • 円安もあるし、脱クラウドの流れが今後日本でも来るかもしれない。プログレのカウンターでパンクが流行る、みたいな・・・
  • というか喋りおもろすぎるだろ DHH。主張に関しては留保付きだが人間としては魅力的。
• Prisma Postgres®: Building a Modern PostgreSQL Service Using Unikernels & MicroVMs
  • Prisma のポスグレマネージドサービス。これも結局 MongoDB とか Redis と同じで、OSS 持ってる企業がインフラ提供して露命をつなぐパターンってことだよね。

仕事。なんとなく出社する。久々に人と話せて良かった。仕事はちょっとギアを入れなきゃならならそう。

11月じゃん…。スーガクちょっとやって仕事の実装。芋煮作る。里芋剝くのが面倒くさすぎる。味が薄すぎる。

---

• 恥ずかしい話。Tone.js を使って、6個ぐらいの mp3 ファイルを直列に読み込んでいた。

• メモリが貧弱な Android 端末でクラッシュした。

  • 端末を PC と接続して、Chrome のプロファイラを見た。
    • Performance タブは正常、Memory タブを見ても JS Heap は 10 MB ぐらいしか使っていない。どう見てもメモリ不足で落ちてるんだけど、原因をはっきり特定できない状態。
    • mp3 ファイルも最大で 10MB 程度しかないので、仮に全部メモリに乗ったとしてもそんなに問題ない感じ。
  • adb shell top -d 1 でメモリの使用状況を確認した。
    • すると、クラッシュするまで継続的に 1GB ぐらい全体のメモリ使用量が増大し続けていた。
  • 調べたところ、Tone.js が依存している decodeAudioData() はメモリをかなり消費することがわかった。
    • decodeAudioData()は、圧縮された MP3 ファイルを非圧縮の PCM データに展開するもの。PCM データのサイズはサンプリングレートが 44,100Hz だとしたら、デフォルトが 32bit PCM、2ch なので 44100 * 4 * 2 = 352,800 B/秒。したがって、5分の長さのファイルをデコードするのに少なくとも 100MB 以上のメモリを確保する必要があることになる。
      • 本当は 45 秒ぐらいの音声ファイルに対して使うことが想定されてるらしい
    • 一時的に 100MB 必要になるのならまだ許せる。問題はなぜデコード処理を何回も連続して呼び出すと 1GB 消費してしまうかだが、デコード処理はネイティブのレイヤーで行われるため、実行エンジンによる GC のタイミングと厳密に同期しない。そのため、非同期処理が見かけ上終了して AudioBuffer が参照されなくなっても、確保されたメモリがちょっとだけ居残ってしまうのではないか。
  • ところで、なんで 1GB もメモリをデコードに使ってたのに、 プロファイラの Peformance タブ、Memory タブにそれが反映されてなかったのか？

• そもそも誤解していたんだけど、ざっくりブラウザにはネイティブメモリとJS Heap、二種類のメモリ領域があるっぽい（超ざっくり）。

  • Chrome のタスクマネージャを開くと、“Memory” と “JavaScript Memory” 、2つのカラムがあって、前者がネイティブメモリ、後者が JS Heap に対応している。ネイティブメモリの使用状況は Peformance, Memory タブでは確認できない。確認できるのは JS Heap の内容だけ。つまり、JavaScript の配列、オブジェクト、関数、ArrayBuffer、TypedArray とか。
  • Performance API （performance.memory() や performance.measureUserAgentSpecificMemory()） も JS Heap の情報しか取得できない。
  • 一方で decodeAudioData() みたいな 、JavaScript と別スレッドで動くネイティブの処理には、当然ネイティブメモリが使われることになる。つまり、デコードのための一時バッファなど。
  • このことを知ってからタスクマネージャでページを確認すると、やはり 800MB ほどネイティブメモリをデコードに使っていた…。使いすぎィ！
    • ネイティブメモリの中身を見る方法ってないのかな、 chrome://tracing とかでわかるんか？

• 【学び】メモリの貧弱なモバイル端末では、ネイティブメモリの使用量も意識しなければならない / タスクマネージャを見なければわからないこともある（戒め）

仕事。なんかシャキッとしなささがあるな。手は動かしてるけどなんかインパクトに欠けるというか。なんかどうでもいいものを作ってる気がする。ハンバーグ作る。神バーグできた。神田の古本まつり行きたい。

---

• We’re forking Flutter. This is why.
  • Flutter の霊圧が・・・
    • Flutter 開発チームの仕事がとにかく遅かったんでフォークしたわ！ってことらしい。
    • 自分の人生で Flutter 書くことってもうあるんかな　ない気がする