HTTP ストリーミングを使用した WebSocket フォールバックでXmlHttpRequest#responseTextは、変更のたびに呼び出されるreadystate(そして >= 3) ことがわかります。
WHATWGの生活水準によると、テキスト応答は
...
decodeフォールバック エンコーディング文字セットを使用して受信したバイトを実行した結果。
このような変更のたびに、HTTP ストリーミングのリクエスト以降に受信したデータをすべてUTF-16 にエンコードした結果に対応するサイズの新しい文字列が作成されるということだと思います。readystate
毎秒約 5 つのメッセージがクライアントに着信するこの手法を使用すると、JavaScript ヒープで大量のメモリ チャーンが定期的に (つまり、HTTP ストリーミング応答バッファが大きくなる期間 - 定期的にリセットされる) 観察されました。上記のアプローチにリンクされています。
これは合理的な分析に聞こえますか?
この HTTP ストリーミング手法のメモリ サブシステムへの影響を軽減する手法を見つけた人はいますか (たとえば、各 HTTP ストリーミング接続の寿命を短くするなど)?